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ABSTRACT 


Relational  database  technology  is  examined  as  a  means  to 
support  computer  Risk  Assessment  at  the  Naval  Postgraduate 
School.  The  current  methodology  for  conducting  computer  Risk 
Assessment  within  the  Department  of  the  Navy  is  used  to 
construct  an  initial  design  for  a  relational  database  system. 
The  initial  design  focuses  on  computer  asset  identification 


and  valuation  as  the  first  step  of  the  computer  Risk 

/ 

Assessment  process.  yC'  ? ./-?■•/  '  . ^ 
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I.  INTRODUCTION 


A.  BACKGROUND 

The  rap’d  growth  in  computer  technology  has  brought 
about  a  tremendous  increase  in  computer  applications  by 
the  federal  government.  Computer  proliferation  has  been  so 
dramatic  that  it  has  outstripped  the  ability  to  control  it. 
In  many  cases.  government  has  not  even  been  able  to  maintain 
accurate  inventories  of  how  much  computer  equipment  has  been 
bought  or  who  has  it. 

In  1976.  "The  General  Accounting  Office  (GAO)  was  able 
only  to  bracket  Federal  data  processing  spending  as  between 
$3  billion  and  $10  bJ 11  ion  annually.  More  recently.  the 
Office  of  Management  and  Budget  (0MB)  has  cited  a  figure  of 
$5.5  billion.  and  the  General  Services  Administration  (GSA) 
has  estimated  the  cost  of  software  development  and 
maintenance  alone  at  $2.2  billion."  [Ref.  1] 

More  serious  than  the  problem  of  controlling  computer 
acquisition.  is  the  problem  of  computer  security.  Hand 
in  hand  with  computer  growth  is  the  increased  dependence  on 
computers  for  everything  from  Early  Warning  Detection  Systems 
for  national  defense  to  word  processing  systems  for  routine 
administration  support.  Increased  dependence  on  Automatic 
Data  Processing  (ADP)  to  support  mission  accomplishment 
increases  the  need  to  protect  those  ADP  resources. 
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ADP  security  is  not  limited  to  protection  against 
wrongful  disclosures  or  physical  assault  against  an  ADP 
activity.  In  general.  ADP  security  encompasses  threats  to 
ADP  property  and  capital  equipment  and  the  physical  hazards 
to  continuing  operations.  For  example.  hardware  failures, 
failure  of  supporting  utilities,  disasters,  nonavailability 
of  personnel.  neighboring  hazards.  tampering  with  input, 
programs,  or  data  files  used  for  fraudulent  purposes.  and 
interception  of  acoustical  or  electromagnetic  emanations  from 
ADP  hardware  are  all  part  of  the  ADP  security  problem.  ADP 
resources  are  vulnerable  to  a  wide  assortment  of  threats. 

A  problem  of  this  magnitude  requires  the  utmost 
attention  and  concentrated  effort  of  the  entire  ADP 
organization.  The  security  solution  starts  with  the 
establ i shment .  implementation,  and  maintenance  of  a  physical 
security  program. 

Analysis  of  risks  to  ADP  security  is  an  essential  part 
of  a  physical  security  program.  Risk  analysis  involves  the 
identif’cation  of  what  is  at  risk  and  what  those  risks  are. 
"The  primary  purpose  of  risk  analysis  is  to  understand  the 
security  problem  by  identifying  security  risks.  determining 
their  magnitude.  and  identifying  areas  where  safeguards  or 
controls  are  needed."  [Ref.  2]  Besides  determining 
how  much  protection  is  required,  risk  analysis  determines  how 
much  protection  already  exists.  Risk  analysis  can  also  be 
used  to  determine  the  amount  of  resources  needed  for 
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security  and  where  to  allocate  those  resources.  "The  aim  of 
risk  analysis  is  to  help  ADP  management  strike  an  economic 
balance  between  the  impact  of  risks  and  the  cost  of 
protective  measures."  [Ref.  3] 

The  results  of  risk  analysis  provide  management  with 
information  which  it  can  use  to  make  decisions  regarding 
which  course  of  action  to  pursue  in  providing  security. 
As  a  result.  it  is  best  to  present  the  estimates  of  loss 
or  damage  in  quantitative  terms. 

The  risk  analysis  process  is  not  something  that  is  done 
one  time  and  filed  away.  "It  must  be  performed  periodically 
to  stay  abreast  of  changes  in  mission.  facilities,  and 
equipment."  [Ref.  4]  Naval  activities  with  ADP  equipment 
are  required  by  OPNAVINST  5239. 1A.  to  update  their  risk 
assessments  at  least  every  five  years  besides  performing  new 
assessments  for  any  changes  in  equipment,  software,  operating 
procedures,  or  any  change  that  might  affect  overall  security 
of  the  system.  [Ref.  5] 

The  federal  government  must  approach  both  these  security 
and  control  problems  in  an  economical  manner.  The  government 
has  issued  guidelines  on  risk  analysis  including  an  approved 
methodology  for  implementing  a  risk  management  program. 
The  environment  for  computer  resource  control  is  different 
than  that  of  computer  security.  Congress  has  spearheaded  the 
effort  to  control  the  ballooning  growth  in  computer  resources 
by  passing  laws  to  strictly  control  resource  acquisition. 

1 1 


The  terms.  system  development  and  system  design.  refer 
to  different  levels  of  computer  system  development.  System 
design  is  a  subset  of  the  system  development  process.  The 
system  design  process  involves  two  phases  that  fall  between 
the  user  requirements  analysis  phase  and  the  implementation 
phase  of  the  overall  system  development  process. 

The  term  user.  for  this  problem,  refers  to  the  end-user 
of  the  computer  system.  The  computer  system  is  designed  to 
provide  direct  support  to  the  user.  Direct  support  is 
stipulated  because  the  end-user.  in  this  case,  implies  some 
interaction  on  the  part  of  the  user  with  the  computer  system. 

A.  THE  DATABASE  DESIGN  PROCESS 

There  are  two  basic  approaches  to  database  design:  top- 
down  and  bottom-up.  Making  a  decision  between  these  two 
philosophies  is  usually  based  on  whether  there  is 
already  a  large  investment  in  conventional  files  and 
programs.  If  this  is  the  case.  then  the  bottom-up  approach 
is  generally  more  feasible.  Here.  one  application  at 
a  time  is  selected  for  conversion  and  the  database  is 
extended  by  stages.  One  problem  with  this  approach  is  the 
final  database  could  end  up  being  far  from  optimal. 

The  top-down  approach  is  the  preferred  approach  and  is 
best  used  when  creating  a  new  system.  preferably  where 
Uttle  conversion  is  required.  The  goal  is  to  produce  a 
rational,  integrated  solution  to  business  information  needs. 
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PHASE  1 


PHASE  2 


PHASE  3 


PHASE  4 


PHASE  5 


Figure  2.1  Relational  Database  System  Development  Process 


1 1 .RELATIONAL  DATABASE  DESIGN  OVERVIEW 


This  chapter  concentrates  on  the  first  three  phases  of 
the  system  development  process;  user  requirements  analysis, 
logical  design,  and  physical  design.  These  later  two  phases, 
the  logical  design  and  physical  design  are  part  of  the 
database  design  process.  A  short  explanation  of  the  system 
development  process  and  the  system  design  process 
follows.  A  brief  definition  of  user  is  also  provided. 

In  computer  science  literature.  there  have  been  many 
different  terms  used  to  describe  the  various  phases  of  the 
system  development  process.  To  help  simplify  the  discussion 
in  this  thesis,  the  five  basic  development  phases  will  be 
called  user  requirements  analysis.  logical  design.  physical 
design,  implementation.  and  maintenance.  These  five  phases 
are  illustrated  in  Figure  2.1.  The  products  of  the  different 
phases  are  also  shown.  To  differentiate  between  products  and 
development  phases.  rectangles  are  used  to  denote  phase  end- 
products  and  ovals  are  used  to  denote  phases.  For  example, 
the  rectangle  containing  the  "Log1' cal  Schema"  is  the  end- 
product  of  the  oval  containing  the  "Logical  Design"  phase. 

There  have  also  been  many  terms  used  to  describe  the 
different  phases  of  system  design.  For  our  purposes.  the 
terms  used  in  Figure  2.1  to  discuss  system  development.  will 
be  used  to  discuss  the  design  process  as  well. 
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This  first  chapter  has  discussed  the  importance  of  and 
requirements  for  maintaining  effective  control  of  computer 
resources.  The  concept  of  database  systems  as  a  means  to 
effect  control  has  also  been  introduced.  Database  technology 
will  be  discussed  in  greater  detail  in  later  chapters. 
Specifically.  a  relational  database  initial  design  is 
proposed  as  a  means  to  provide  necessary  support  for  a 
control  and  risk  analysis  program  for  the  Naval  Postgraduate 
School  . 

Chapter  Two  will  present  an  overview  of  the  relational 
database  design  process.  Advantages  of  using  the  relational 
data  model  will  also  be  addressed.  Chapters  Three.  Four,  and 
Five  detail  the  specification.  logical  database  design,  and 
the  physical  database  design  phases  respectively,  to  create  a 
database  to  control  computer  resources.  Chapter  Six 
examines  the  process  of  database  implementation.  involving 
the  selection  of  a  DBMS.  Chapter  Seven  evaluates  the 
database  design  process  and  discusses  the  concept  of  design 
iterations  as  a  means  toward  design  optimization.  Chapter 
Eight  presents  the  initial  design  in  tne  context  of  the 
overall  database  project  and  recommends  follow-on  thesis  work 
to  complete  the  project.  Conclusions  are  then  drawn  about 
initial  database  design.  the  iterative  design  process.  and 
database  implementation.  Relational  database  design  and 
database  administration.  in  the  context  of  risk  assessment, 
are  also  highlighted. 


These  advantages  and  disadvantages  characterize  database 
systems  in  general.  M i c roc omputer  systems,  however.  do 
not  exhibit  many  of  the  disadvantages  noted  above  while 


TABLE  I 


Advantages  of  Database  Processing 


1 . 

More  Information  from  the 

Same  Amount  of  Data 

2. 

New  Requests  and  One-of-a 
Impl emented 

-Kind  Requests  More  Easily 

3. 

Elimination  of  Data  Dupli 

cation 

4. 

Program/Data  Independence 

5. 

Better  Data  Management 

6. 

Affordable  Sophisticated 

Programming 

7. 

Representation  of  Record 

Relationships 

Disadvantages  of  Data  Processing 

1.  Expensive  to  develope 

2 .  Complex 

3.  Recovery  More  Difficult 

4.  Increased  Vulnerability  to  Failure 


maintaining  most  of  the  advantages.  This  is  an  important 
argument  in  favor  of  m i c r oc ompu t e r  DBMSs  that  will  be 
explored  in  a  later  chapter. 
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complex  software  package  can  cost  hundreds  of  thousands  of 
dollars.  Additionally,  where  existing  applications  protfolios 
are  large,  conversion  costs  associated  with  going  to  the 
database  system  approach  can  be  expensive.  Less  quantifiable 
costs  of  the  database  approach  include  tne  possibility  of 
reduced  system  reliability,  emphasis  on  global  optimization 
of  information  usage  resulting  in  users  r e 1  i  n q u  i  sh  i  n g  their 
power  to  make  information  decisions  on  a  strictly  local 
basis,  and  the  reduction  of  data  processing  efficiency. 

Database  technology  is  troubled  by  the  problem  of 
efficiency.  Database  systems  tecnnology  involves  the 
requirement  for  extensive  overhead  processing  of  each  file  on 
each  access  to  the  database.  If  traditional  throughput  rates 
are  to  be  maintained.  additional  equipment  in  the  form  of 
faster  processors  and  additional  memory  will  have  to  be 
acquired.  Also.  expertise  is  required  to  design,  manage, 
support,  and  maintain  the  database. 

Another  problem  with  database  systems  is  that  they  are 
more  vulnerable  to  errors.  In  the  traditional  multi-file 
approach.  any  errors  that  were  introduced  into  the 
independent  and  often  redundant  files  were  not  likely  to 
propagate  beyond  the  immediate  vicinity.  With  the  database 
system.  there  is  the  possibility  that  errors  could  spread 
further  and  in  unanticipated  directions.  Table  I  summarizes 
the  advantages  and  disadvantages  associated  with  database 
processing. 
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Finally.  t  h  p  DBMS  environment  enables  the  user  to 
perform  more  sophisticated  information  retrievals. 

Before  going  on  to  the  disadvantages  of  database  systems, 
detail.  Data  independence  proposes  to  alleviate  the 
problems  created  by  making  changes  in  programs  and  files 
that  necessitate  reorganizing  files  or  impact  all  other 
files  or  programs  tnat  are  used  in  any  organized  system.  It 
is  also  intended  to  solve  the  problems  of  users  not  being 
ablp  to  tailor  files  to  a  specific  application  need.  Data 
independence  allows  any  user  or  group  of  users  to  have  a  view 
of  the  database  that  is  different  from  the  views  used  by 
others.  Thus.  a  change  made  to  accommodate  one  user  can  be 
kept  invisible  to  others;  a  change  made  to  the  structure  of  a 
file,  or  to  the  storage  device  characteristics,  can  be  hidden 
from  all  users;  and  each  user  can  be  given  a  view  of  the 
database  that  includes  only  the  relevant  contents  in  a  form 
well  suited  to  the  users  needs.  [Ref.  14] 

Data  independence  is  not  an  automatic  benefit  of  using  a 
database.  On  the  contrary.  adopting  the  database  approach, 
with  its  emphasis  on  sharing  of  data,  causes  the  problem  that 
data  independence  ,:s  intended  to  alleviate. 

2 .  D i sad van tage s 

The  benefits  of  database  tecnnology  do  not  come 
without  certain  costs;  both  financial  and  nonfinancial.  The 
most  visible  financial  cost  of  the  database  approach  '  s 
associated  with  the  acquisition  of  a  DBMS.  This  large  and 
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different  files  is  not  available  due  to  the  artificial 
partitioning  in  a  file  processing  system.  A  DBMS.  in 
contrast.  does  not  partition  the  data.  Therefore  more 
information  can  be  produced  from  a  given  amount  of  data  and 
more  knowledge  is  available  for  decision  making. 

Another  advantage  of  database  processing  is  the 
reduction  or  elimination  of  data  duplication.  By  reducing 
data  redundancy,  the  database  structure  makes  more  efficient 
use  of  computer  storage  space.  Additionally,  the  problem  of 
data  integrity  is  reduced.  It  is  much  easier  to  maintain  a 
single  instance  of  a  data  element  than  it  is  to  maintain  two 
or  three  instances  of  the  same  data  element.  Reducing  data 
duplication  can  also  result  in  faster  processing  and  data 
entry. 

Another  advantage  of  database  processing  is  that  it 
allows  for  program  -  data  independence.  Programs  do  not  have 
to  be  changed  when  the  data  structure  is  changed  because 
programs  access  data  indirectly  through  the  DBMS.  In 
general,  only  the  database  structure.  specific  programs,  and 
sometimes  the  DBMS  need  to  be  changed  when  a  field  is  added 
to  a  database  record  or  a  new  technique  for  processing  files 
is  implemented.  [Ref.  13] 

The  benefits  of  economies  of  scale  are  another  advantage 
of  database  processing.  Improvements  made  to  the  database 
benefit  all  users  and  not  only  users  of  a  particular 
appl ication. 
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was  generally  not  compatible  with  other  programs.  In  other 
words,  there  was  great  difficulty  in  integrating  application 
programs  to  work  together  if  they  were  not  originally 
designed  to  do  so.  Additionally,  maintenance  of  the 
programs  was  becoming  unmanageable  due  the  constant  demand 
for  minor  changes  in  the  programs. 

The  second  major  factor  was  the  development  of  a 
specific  software  package  designed  by  IBM  to  support  the 
APOLLO  project.  North  American  Rockwell.  the  prime 
contractor  for  the  project.  needed  a  way  to  organize  and 
coordinate  the  vast  collection  of  research  and  production 
groups  and  to  ensure,  on  a  technical  level,  that  each  of 
millions  of  individual  components  would  correctly  fit  into 
the  entire  assembly  and  work  properly  with  all  the  other 
parts  supplied  by  all  the  other  firms  [Ref.  12]. 

The  result  was  the  Generalized  Update  Access  Method 
(GUAM).  developed  in  1964  by  IBM.  GUAM  was  designed  to  deal 
with  data  whose  logical  structure  was  hierarchical  and  for 
second-generation  hardware  which  relied  heavily  on  the  use  of 
magnetic  tape. 

1 .  Advantages 

Database  processing  provides  several  advantages  over 
traditional  file  processing.  In  file  processing  systems, 
the  data  is  stored  in  files  which  are  considered  to 
be  independent  of  one  another.  Consequently.  information 
that  could  be  produced  by  processing  data  stored  in  two 


propose  a  database  design  for  applicat;on  to  the  risk 
analysis  and  computer  control  problems. 


D.  WHY  DATABASE 

A  database  is  a  collection  of  integrated  files.  It  is 
integrated  in  the  sense  that  it  stores  relationships  among 
the  records  in  those  files.  A  database  also  contains  a 
description  of  its  own  structure.  The  database  is  accessed 
by  a  usually  large  complex  program  called  the  Database 
Management  System  (DBMS).  The  DBMS  fills  the  role  of  data 
manager,  which  brings  together  an  organization's  data  so  that 
it  can  be  readily  available  to  many  different  users  and 
applications.  The  DBMS.  besides  storing  data.  stores  a 
description  of  the  format  of  the  data. 

There  are  two  major  factors  that  led  to  the  development 


of  database 

systems. 

The  first  was  motivated  by  the 

gradual 
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o  f 

these  applications  could  not  be  used  for  purposes  beyond  that 
which  they  were  specifically  developed.  This  was  due  to  the 
fact  that  specific  applications  were  created  without  regard 
to  other  applications  outside  the  scope  of  the  problem  each 
was  being  designed  to  solve.  Each  appHcc  on  was  unique  and 
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demonstrating  the  concern  for  computer  security  at  the 
highest  levels  of  government.  In  Circular  A -  7 1  .  0MB 
established  minimum  controls  for  computer  security  and 
required  that  every  agency  implement  them  through  a  computer 
security  program.  [Ref.  11]  In  December.  1978.  the 
Department  of  Defense  issued  DOD  Directive  5200.28  entitled 
"Security  Requirements  for  Automatic  Data  Processing  (ADP) 
Systems".  This  directive  established  policy  for  the 
protection  of  classified  material  in  ADP  systems.  The 
Department  of  the  Navy  issued  OPNAVINST  5239.1  in  April. 
1979.  This  instruction  implemented  the  requirements  put 
forth  in  0MB  Circular  A  -  7 1  and  DOD  Directive  5200.2  8. 
Specifically.  it  directed  all  activities  operating  computer 
systems  to  appoint  an  ADP  Security  Officer  who  would  be 
responsible  for  conducting  risk  assessments  on  a  periodic 
basis. 

In  August  1  982  .  CPNAVINST  52  3  9  .  1  A  was  released  which 
is  the  current  directive  governing  ADP  security  requirements. 
This  instruction  provides  a  comphrehensive  review  of  the 
Navy's  ADP  security  program  including  the  Department  of 
the  Navy  (DON)  approved  risk  assessment  methodology.  It  is 
from  this  instruction  that  the  data  requirements  for  the 
computer  asset  database  model  for  this  thesis  are  determined. 

What  follows  is  a  discussion  of  the  origins  for  database 
systems  and  a  look  at  database  systems  technology  advantages 
and  disadvantages.  This  discussion  supports  my  decision  to 


C.  ADP  SECURITY  DIRECTIVES 

ADP  security  is  receiving  attention  at  every  level  of 
the  executive  branch.  The  Office  of  Management  and  Budget 
(0MB)  was  assigned  responsibility  for  the  oversight  and 
policy-making  functions  applicable  to  computer  systems 

development  and  acquisition  by  the  Brooks  Act  of  1965.  In 
1972.  "0MB  urged  private  industry  --  hardware  manufacturers, 
software  houses  and  related  service  industries  --  to  make 
greater  capital  investments  in  computer  security.  At  the 
time.  the  Federal  Government  was  concerned  that  its 

inability  to  protect  data  in  computer  systems  --  except  at 

very  great  expense  —  was  limiting  its  ability  to  realize  the 

benefits  of  technology."  [Ref.  9] 

Congress.  through  the  Brooks  Act.  also  assigned 
other  Federal  agencies  r e s pon s i b 1 i t i e s  for  ADP  management. 
The  National  Bureau  of  Standards  (NBS)  was  directed  to 

provide  overall  coordination  and  technical  guidance  to  the 
government's  efforts  in  developing  guidelines  and  standards. 
[Ref.  10]  In  June  1974.  NBS  published  Federal  Information 
Processing  Standards  Publication  (FIPS  PUB)  31.  This 
publication.  although  not  a  directive.  was  the  first 
comprehensive  study  for  government  agencies  concerning  ADP 
physical  security  and  risk  management. 

It  was  0MB  Circular  A- 7 1  that  made  Federal  agencies 
start  to  think  seriously  about  computer  security.  The  Office 
of  Management  and  Budget,  relaeased  0MB  C’rcular  A  —  7 1  " n  1978 


purposes  for  which  computers  are  used,  how  they  are  used  and 
the  level  of  expenditures  requested  for  these  activities. 
[Ref.  7]. 

A  significant  obstacle  to  future  automation  is 
the  demanding  Federal  ADPE  acquisition  procedure.  The 
ADPE  acquisition  procedure  requires  extensive  planning  and 
justification  documentation.  Careful  planning  is  necessary 
in  part  due  to  the  long  lead  times  required  in  the  ADPE 
acquisition  procedure.  Justification  of  the  need  for  ADPE  is 
required  as  a  result  of  limited  resources.  The  idea  is  to 
achieve  optimum  efficiency  in  distribution  of  limited  funds. 

The  Navy  can  strengthen  its  argument  for  more  ADPE  if 
it  can  demonstrate  effective  control  of  existing  computer 
assets.  A  system  that  provides  an  accurate  accounting  of 
computer  resources  and  utilization  would  also  aid  the  Navy  in 
making  sure  that  its  resources  are  optimally  utilized. 

Effective  control  of  computer  assets  is  also  essential 
to  effective  computer  security.  Computer  security  is 
implemented  through  an  ADP  security  program  and  an  essential 
part  of  any  security  program  is  risk  assessment.  Risk  ’S 
determined  from  the  evaluation  of  threats  and  vulnerabilities 
in  relationship  to  the  assets  of  the  ADP  facility  [Ref.  8]. 
One  necessary  steps  in  conducting  risk  assessment  is  asset 
identification  and  valuation. 
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The  Brooks  Act.  passed  in  1964.  has  indirectly  compelled 
federal  agencies  to  maintain  accurate  inventories  of  computer 
assets  in  order  to  defend  justification  for  new 
acquisitions. 

Most  organizations.  however.  are  on  their  own  when  it 
comes  to  providing  means  to  control  computer  resources. 
Congress  requires  that  effective  control  be  established, 
but.  it  does  not  provide  guidance  on  how  to  do  it.  In 
contrast.  risk  assessment  is  supported  by  a  well  defined 
methodology  that  is  recommended  to  solve  this  problem. 

B.  THE  NAVY'S  NEED  TO  CONTROL  COMPUTER  ACQUISITION  AND 

SECURITY 

The  Navy  has  made  a  large  investment  in  computer 
resources.  The  automatic  data  processing  ( A 0 P )  budget  for 
the  Navy  in  EY85  was  approximatly  $1,961,000,000.00 
[Ref.  6],  This  figure  represents  an  increase  over  FY84  of 
close  to  25  percent  and  the  rate  of  growth  has  been 
increasing  in  recent  years. 

Management  and  control  of  these  resources  has  become  a 
serious  problem.  The  ability  to  effectively  and  efficiently 
manage  these  resources  will  impact  future  ADPE  acquisition  in 
the  Navy.  Various  committees  and  individual  members  of 
Congress  have  expressed  concern  about  the  increasing  level  of 
Federal  expenditures  for  data  processing  and  have  requested 
agencies  to  provide  information  to  the  Congress  on  the 
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The  top-down  database  design  methodology  follows  a 
sequence  of  steps.  Each  step  considers  different  problems  of 
database  design  at  different  levels  of  detail.  This  staged 
approach.  in  contrast  to  ad  hoc  design.  both 
formalizes  the  design  process  and  simplifies  it.  The 
sequence  of  design  stages  and  the  design  tools  used  at  each 
stage  is  called  a  design  methodology.  [Ref.  15] 

There  are  several  different  design  methodologies  for 
top-down  design  in  use  today.  One  class  of  these 
methodologies,  the  databased  methodology,  concentrates  on 
enterprise  data.  Enterprise  data  refers  to  the  facts  and 
information  that  are  used  by,  and  part  of  the  organization 
that  is  being  looked  at.  The  design  begins  by  defining  data 
elements  and  structures  in  the  user  system.  Then,  user 
functions  are  defined.  The  relationship  between  data  and 
function  is  usually  expressed  graphically.  Data  in  databased 
methodologies  are  usually  described  by  a  data  model  or 
semantic  model. 

It  is  important  that  a  model  be  chosen  that  captures  the 
essential  features  of  the  organization's  data.  The  data 
model  is  an  important  design  tool  in  the  database  development 
process.  The  Relational  Model  will  be  used  to  design  the 
Computer  Risk  Assessment  Asset  Identification  Database.  The 
advantages  of  the  Relational  Model  will  be  discussed  later. 

In  general  terms,  the  design  process  consists  of  two 
phases.  The  first  phase  concentrates  on  the  user's 


MnlaMMallil! 


26 


requirements  and  building  a  conceptual  database  structure 
that  is  a  model  of  the  organization.  This  is  the  logical 
database  design  phase.  The  second  phase  is  the  physical 
database  design  phase.  The  designer  must  construct  the 
physical  database  given  the  logical  design  and  an 
implementation  model. 

B.  WHAT  IS  A  RELATIONAL  DATABASE 

There  are  three  objectives  which  a  formal  model  should 
meet.  These  are: 

1.  It  can  be  used  to  identify  user  requirements  and 
present  them  in  a  way  that  is  easily  understood  both 
by  users  and  by  computer  professionals. 

2.  It  can  be  easily  converted  to  a  technical 

i  m  pi  erne  n  ta  t  i  o  n  . 

3.  It  provides  rules  and  criteria  for  efficient  logical 
data  representation.  [Ref.  16] 

The  relational  model  meets  the  first  objective  because 
it  provides  an  interface  that  both  users  and  designers  can 
easily  and  unambiguously  comprehend.  This  is  accomplished 
by  using  tables.  The  organ  i  za t i ona  1  data  is  specified 
as  a  set  of  tables  or  relations. 

The  next  objective  is  also  satisfied  with  a  relational 
model  because  it  can  be  directly  implemented  on  a  machine 
through  a  DBMS.  Several  different  systems  are  currently 
available  on  the  market.  Another  solution  would  be  to 
convert  the  relational  model  to  a  different  physical 
str ucture  . 
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The  last  objective  relates  to  criteria  for  good  logical 
design: 

1.  Each  fact  should  be  stored  once  in  the  database. 

2.  The  database  should  be  consistent  following  database 
operations. 

3.  The  database  should  be  resilient  to  change. 

These  criteria  are  realized  through  a  process  called 
normalization.  "Normalization  rules",  as  defined  by  William 
Dent.  "are  designed  to  prevent  update  anomalies  and  data 
inconsistencies."  [Ref.  17] 

Another  aspect  of  the  relational  model  is  that  it  must 
provide  languages  to  access  relations.  The  relational  model 
language  is  particularly  successful  for  two  reasons.  First, 
relational  languages  are  particularly  sensitive  to  human 
factors.  i.e.,  provide  a  natural  interface.  Second,  it  has 
strong  selective  power.  That  is.  it  can  retreive  data 
that  satisfy  any  condition  covering  any  number  of  relations. 
[Ref.  18] 

The  goal  of  relational  design  is  to  structure  the 
database  as  a  set  of  normal  relations.  The  process  begins 
by  defining  data  elements  or  attributes.  After  identifying 
all  the  data  elements.  determine  how  each  element  relates  to 
the  other  and  then  assemble  one-to-one  related  elements  into 
records.  The  other  half  of  the  picture  is  the  relational 
data  access  language  which  is  used  to  both  maintain  tne 
data  and  to  turn  it  into  inf.  'mation. 


Figure  2.2  provides  an  illustration  of  a  relation.  This 
example  of  a  relation,  named  INVENTORY,  appears  in  nearly  the 
same  form  as  a  paper  inventory  form  it  represents.  The 
INVENTORY  relation  contains  information  about  supply  parts; 
it  stores  each  PAR T_ NUMBER.  QUANTITY.  DESCRIPTION.  PRICE, 
and  TOTAL . 


RELATION:  INVENTORY 


PART_NUMBER 

QUANTITY 

DESCRIPTION 

PRICE 

TOTAL 

linn 

1 

FAN  BELT 

2.00 

2.00 

222222 

2 

WHEEL 

20.00 

40.00 

333333 

1 

CYLINDER 

30.00 

30.00 

444444 

3 

TIRE 

30.00 

90.00 

Figure  2.2  Relation  INVENTORY 


Each  relation  possesses  the  following  properties: 

1.  There  is  one  column  in  the  relation  for  each 
attribute  of  the  relation.  Each  such  column  is 
given  a  name  that  is  unique  in  tne  relation. 

2.  The  entries  in  the  column  come  from  the  same  domain. 
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3.  The  order  of  the  columns  or  attributes  in  the 
relation  has  no  significance. 

4.  The  order  of  the  rows  is  not  significant. 

5.  There  are  no  duplicate  rows.  [Ref.  19] 

C.  THE  ENTERPRISE  MODEL 

The  product  of  the  user  requirements  analysis  phase, 
referring  to  Figure  2.1.  is  called  the  design  specification. 
In  performing  the  requirements  analysis,  it  is  helpful  to 
decompose  the  problem  into  a  group  of  smaller  modules.  A 
major  part  of  this  analysis  process  focuses  on  the  enterprise 
and  the  result  of  this  anaylsis  produces  what  is  called  the 
enter pr i se  model . 

The  enterprise  model  is  a  high  level.  static  abstraction 
of  the  organization.  It  shows  the  major  functions  performed 
and  the  flows  of  information  in  support  of  them. 


The  goal 

i  s 

for  the  database 

to  model  the  enterpri 
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i s  designed 
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serve  and  be 

consi stent  wi th 
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Events  that  occur  in 
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be  represented 

by  transactions  in 

the 

model  . 

The  model  should  represent  all  functions  and  data 
elements  that  are  part  of  the  enterprise.  The  database 
exists  so  that  users  can  store  and  retrieve  information  about 
things  in  the  real  world.  Naturally.  it  is  impractical  to 
store  every  minute  detail  about  an  organization. 
Consequently,  a  certain  amount  of  data  aggregation  and 


generalization  is  required  by  the  database  designer  to 
construct  a  working  model.  Additionally.  the  data 
relationships  of  the  organization  should  be  represented  in 
the  enterprise  model. 

0.  LOGICAL  DATABASE  DESIGN 

The  logical  design  phase  is  centered  around  the  user 
characteristics  of  the  database.  The  inputs  to  this  phase 
are  the  system  requirements  and  the  project  plan.  The 
requirements  are  expressed  as  data  flow  diagrams,  policy 
statements,  and  the  data  dictionary. 

The  logical  design  specifies  the  logical  format  of  the 
database  including  the  records  to  be  maintained.  their 
contents,  and  relationships  among  the  records.  [Ref.  20]  The 
product  of  this  phase  is  called  the  logical  schema. 

Logical  database  records  are  specified  from  analysis  of 
the  enterprise  model.  The  number  of  records  required  is 
directly  proportional  to  the  level  of  detail  of  the 
enterprise  model  and  consequently  the  relational  model.  The 
contents  of  the  records.  names  of  fields  and  their  format, 
are  also  determined  during  the  logical  design  phase. 

The  major  steps  in  the  logical  design  development  phase 
are  listed  in  Table  II. 

In  general.  the  contents  of  the  data  dictionary  are  used 
to  define  the  logical  and  user  views.  The  policy  statements 
aid  the  development  of  the  descriptions  of  logical  database 
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processing  and  the  requirements  are  used  to  verify  the 
completeness  of  the  logical  design.  [Ref.  21] 

TABLE  II 

Stages  of  Logical  Database  Design 

1.  Identify  data  to  be  stored 

2.  Consolidate  and  clarify  data  names 

3.  Develop  the  logical  schema 

4.  Define  processing 

5.  Review  design 

E.  PHYSICAL  DATABASE  DESIGN 

The  second  phase  of  database  design  is  highly  dependent 
on  the  DBMS  being  used.  In  this  phase,  the  logical  schema  is 
transformed  into  the  data  constructs  available  with  the 
particular  DBMS.  The  outputs  from  this  phase  are  the 
specification  of  the  physical  schema  and  the  definition  of 
user  v iews . 

The  relational  model  provides  a  vocabulary  for 
describing  the  structure  and  processing  of  the  database. 
These  tasks  are  accomplished  by  the  two  major  components  of 
the  model.  the  Data  Definition  Language  (DDL).  and  the  Data 
Manipulation  Language  (DML). 


The  goal  of  the  design  process  is  to  produce  a 
specification  that  can  be  used  to  implement  the  database 
using  a  commercial  DBMS.  [Ref.  22] 

The  following  three  chapters  will  step  through  this 
entire  process.  The  next  step  is  to  begin  the  user 
requirements  analysis  of  the  risk  assessment  and  computer 
control  environment  at  the  Naval  Postgraduate  School.  This 
will  produce  an  enterprise  model  and  and  a  description  of  the 
data  elements.  These  products  will  then  be  used  to  perform 
the  logical  database  design  followed  by  the  physical  database 
design. 
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III.  USER  REQUIREMENTS  ANALYSIS 


The  user  requ ir ement s  analysis  phase,  referring  to  Figure 
2.1.  involves  four  steps:  problem  recognition,  evaluation, 
specification.  and  review.  The  first  step,  problem 
recognition,  has  already  been  covered  in  Chapter  I.  The  next 
step.  problem  evaluation,  involves  analysis  of  the  flow  and 
structure  of  information  to  build  user  specifications. 

A.  USER  ENVIRONMENT 

OPNAVINST  5  2  3  9  .  1  A  provides  detailed  guidance  on  risk 
assessment  methodologies.  Two  methodologies  are  recommended. 
Methodology  I  is  the  more  complex  method  and  the  standard  for 
most  ADP  environments.  It  is  this  methodology  that  w'll  be 
used  for  user  requirements  analysis  and  to  produce  an  initial 
database  system  design  for  NPS. 

Risk  assessment  methodology  I  can  be  broken  down  ;nto 
five  steps  as  shown  in  Figure  3.1.  The  first  step  is  Asset 
Identification  and  Valuation.  Tnere  are  two  basic  parts  to 
the  initial  step.  First.  a  complete,  up-to-date  listing  of 
all  NPS  AO  PE  assets  is  required.  Second.  tne  impact  value 
for  each  asset  must  be  determined  for  each  applicable  impact 
area . 

A  complete  and  accurate  listing  of  computer  assets  is 
essential  f  the  ;sk  assessment  is  to  be  valid. 
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STEP  1 


STEP  2 


STEP  3 


STEP  4 


STEP  5 


Figure  3.1  Major  Steps  of  Method  One  Risk  Assessment 
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maintained  if  it  is  to  Dp  rpliablp.  This  is  the  goal  of  a 
risk  assessment  asset  identification  listing.  This  is  also 
the  goal  of  any  asset  control  mechanism. 

Part  two  of  the  asset  identification  process  involves 
assigning  impact  value  ratings  once  assets  have  been 
identified.  The  procedure  is  to  determine  dollar  amounts  for 
each  of  the  four  ways  in  which  threats  can  impact  an  asset. 
The  four  impact  areas  are  modification.  destruction, 
disclosure  and  denial  of  service. 

1.  Modification  refers  to  the  value  of  software  or 

data  asset  values  based  on  the  cost  to  correct  the 
consequences  of  the  modification  and/or  the  cost  of 
locating  and  recovering  from  the  modification  itself. 
The  value  of  the  assets  should  be  based  on  the  total 
cost  to  detect.  locate.  and  correct  the 

modification.  [Ref.  23] 

2.  Destruction  refers  to  the  value.  including  the 

cost  to  reconstruct  or  replace  the  asset.  as  well 
as.  the  costs  incurred  from  denial  of  service 
caused  by  the  destruction  of  the  asset. 

3.  Disclosure  rpfers  to  the  imnact  of  disclosure  of 
classified  data. 

4.  Denial  of  service  refers  to  the  value  of 
costs  incurred  from  all  denial  of  service,  excppt  for 
that  caused  by  destruction.  [Ref.  24] 

To  simplify  the  process.  estimates  are  provided  for 
impact  und  frequency.  Dollar  values  and  associated  ratings 


are  scaled  by  a  factor  of  ten.  The  sample  range  of  impact 
values  is  shown  in  Table  III. 


TABLE  III 


Impact  Value  Ratings 


Impact  Value  Rating 

$10  1 

$100  2 

$1,000  3 

$1  0  ,000  4 

$100,000  5 

$1,000,000  6 

$10,000,000  7 

$100,000,000  8 


Guidelines  for  Impact  of  Disclosure 
of  Sensitive  Data 


For  Official  Use  Only  $1,000 
Privacy  Act  or  Confidential  $10,000 
Secret  $100,000 
TopSecret  $1,000,000 


This  procedure  requires  the  risk  assessment  team  to  list 
ADP  assets  and  impact  information  on  an  Asset  Valuation 
Worksheet.  An  example  is  shown  in  Figure  3.2. 

NPS  is  presently  in  the  process  of  conducting  its  first 
ADPE  risk  assessment.  There  are  no  established  procedures  or 
in  situ  data  flows.  Because  of  this.  this  thesis  proposes 
that  a  relational  database  design  be  used  to  facilitate 
t  n i s  required  risk  assessment  procedure.  Additionally,  once 
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ASSET  VALUATION  WORKSHEET 


■  .ASSET  NAME 

System  A  Operating  System  and  Support  Programs 

2.  ASSET  DESCRIPTION  AND  JUSTIFICATION  OF  SUPPORT  PROGRAMS 

Operating  system  and  compiler  support  software  for  the  System  'A' 
timesharing  system. 

Impact  of  modification  was  determined  to  be  negligible,  except  in  those  cases  where 
modification  would  result  in  denial  of  service.  Those  figures  were  included  under 
denial  of  service. 

Destruction  was  based  on  total  destruction  of  all  software  and  on-site  backup  tapes. 
These  figures  include  denial  of  service  caused  by  destruction. 

Forty  hours  is  required  for  delivery  and  check  out  of  replacement  O/S  software. 

75  users  denied  service  at  $  12/hour:  plus  6  system  programmers  at  $  14/hour 
for  16  hours:  plus  3  data  processing  technicians  at  $8/hour  for  36  hours.  Total 
for  the  operating  system  -  $36,936. 

Sixty  users  denied  use  of  the  compiler  at  $  12/hour  for  24  hours:  plus  1  system 
programmer  at  $  14/hour  for  8  hours.  Total  for  the  compiler  support 
software  -  $1,832. 

Reconstruction  of  compiler  support  data  based  on  618  hours  to  re-enter  data 
at  $8/hour.  Total  for  compiler  support  data  -  $4,944. 

Disclosure  -  N/A. 

Denial  of  service  was  baaed  on  the  number  of  users  denied  service  for  an  average 
service  outage. 

Operating  system:  35  users  at  $  12/hour  for  1  hour  -  $420. 

Compiler  support  software:  35  users  at  $1 2/hour  for  .5  hours  -  $210. 

Compiler  support  data  -  N/A. 

3.  SUCCESSFUL  ATTACK  FREQUENCY  RATING  BY  IMPACT  AREA. 

□  MODIFICATION  □DESTRUCTION  □DISCLOSURE  □  DENIAL  OF  SERVICE 
N/A  5  N/A  3 

Figure  3.2  Asset  Valuation  Worksheet 
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developed.  the  relational  database  can  also  be  used  to 
control  computer  assets  at  NPS. 

The  number  of  computer  assets  at  NPS  has  been  growing 
rapidly  over  the  past  couple  of  years.  Current  accounting 
for  computer  resources  is  handled  by  several  different 
departments.  The  different  curricular  departments  maintain 
data.  in  the  form  of  copies  of  equipment  receipts.  on  most 
assets  in  their  custody.  The  Computer  Council  is  required 
to  maintain  an  inventory  of  all  hardware  assets 
[Ref.  25].  A  third  point  of  control,  the  supply  department, 
maintains  purchase  account  data  on  most  ADPE  purcnased 
through  the  Navy . 

Clearly.  there  is  not  one  rel-'able  and  easily  accessible 
source  available  to  provide  answers  to  questions  about  ADPE 
resources.  Tne  following  is  a  list  of  questions  that 
department  chairmen  or  the  NPS  Security  Manager  would  like  to 
be  able  to  answer: 

1.  How  much  has  NPS  spent  on  computer  equipment? 

2.  Who  has  custody  of  computer  assets? 

3.  Where  are  computer  assets  located? 

4.  How  much  money  has  been  spent  on  hardware?  on 
software? 

5.  How  many  AST  hoards  are  there?  Where  are  they? 

6.  How  were  the  computer  assets  paid  for? 

7.  How  many  modems  does  NPS  have? 

3.  Is  NPS  providing  enough  security  for  its 
computer  equipment? 
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Figure  3.4  Bachman  Diagram  of  the  Enterprise  Model  for 
Computer  Risk  Assessment  at  NPS 


arrows  represent  the  relationship  between  objects.  Figure 
3.4  shows  the  general  form  of  data  in  the  computer  control 
and  risk  assessment  project.  The  diagram  is  called  a  BACHMAN 
diagram,  or  a  data  structure  diagram.  The  BACHMAN  diagram 
only  shows  the  relationships  among  records.  The  lines 
connecting  the  objects  (entities)  represent  the  relationship 
between  the  ojbpcts  as  one-to-one.  one-to-many.  or  many-to- 
many  depending  on  whether  a  line  has  single  arrowheads  on 
either  end.  double  arrowheads  on  one  end.  or  double 
arrowheads  on  both  ends. 

This  BACHMAN  diagram  modpls  the  global  risk  assessment 
and  computer  resource  control  project. 


TABLE  VII  I  (cont'd) 


SOFTWARE 


COMMUNICATIONS 


INTELLIGENT 

CONTROLLER 

Identify  controllers  that 
are  dPtached  from  main 
processors. 

PRINTER 

Provide  hardcopy  printout. 

OPERATING 

SYSTEM 

Sucn  as  MS  DOS.  UNIX.  CPM. 

APPLICATION 

PROGRAM 

All  specialized  user 
pr ogr  ams  . 

SYSTEM 

UTILITIES 

Generally  resident 
functional  programs  that  are 
used  to  manipulate  data  and 
programs.  Could  be  easily 
confuspd  with  application 
programs. 

TEST  PROGRAM 

Diagnostic  program. 

COMMUNICATION 

Specialized  application 
program.  Could  be  confused 
with  application  program. 

COMM  LINES 

COMM  PROCESSOR 

Specialized,  detached 
hard  ware  . 

MULTIPLEXOR 

Detached. 

SWITCHING 

DEVICES 

Detached. 

MODEM 

All  categories;  micro  to 
ma i n  f r  ame  . 
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TABLE  VIII  ( c o n  t '  d  ) 


MULTIFUNCTION  Specifically  related  to 

BOARD  microcomputers.  De fines  the 

lowest  level  of  asset 
identification  for  control 
of  microcomputer  hardware. 
These  boards  contain  various 
numbers  of  memory  chips. 

I/O  ports,  and  speaker 
h  a  r  d  wa  r  e  . 

DRUM  Secondary  storage. 

DISK  DRIVE  Includes  hard  disk  and 

floppy  disk  drives,  internal 
and  external. 

DISK  PACK  Portable;  separate  from  drive. 

DISKETTE  Floppy  disks. 

TAPE  DRIVE  For  micros  to  main  frames. 

reel-to-reel  and  cassette. 

MAGNETIC  TAPE  Reel-to-reel  only. 

TAPE  CASSETTE  Cassettes  only. 

CARD  PUNCH  Card  punch  machine. 

CARD  READER  Card  reading  machine. 

PUNCHED  CARD  Punched  cards. 

PAPER  TAPE  Punched  paper  tape. 

PAPER  TAPE  Paper  tape  reading  machine. 

READER 

NETWORK  Frontend  processors. 

FRONTEND 

DATABASE  Specialized  database 

MACHINE  processors. 
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TABLE 

VIII 

Table  of  Object 

.  Descriptions 

OBJECT  CLASS 

OBJECT 

DESCRIPTION 

HARDWARE 

CPU 

The  central  processing  unit, 
including  housing  and  chassis. 

Look  at  other  object 
descriptions  to  see  what  other 
object  descriptions  are 
available. 

Note:  If  CPU  is  not  detachable 
from  other  elements  of  the 
computer  system,  then  unit 
will  be  logged  under  the  CPU 
object  type. 

MAIN  MEMORY 

Only  external  main  memory 
units.  Primarily  associated 
with  main  frame  computers. 

I/O  CHANNEL 

External  units  primarily 
associated  with  large  computer 
systems . 

OPERATORS 

Primarily  associated  with 

CONSOLE 

large  computer  systems. 

KEYBOARD 

Detachable  type  keyboards. 

TERMINAL 

Includes  local  and  remote 
types. 

MONITOR 

Detachable  from  other  system 
el ement  s . 

implemented.  problems  will  likely  be  identified  which  will 
necessitate  redefining  the  data  elements  of  the  enterprise. 


TABLE  VII 


Primitives  in  tne  Real  World 


Primitive 


Definition 


Object 


Phenomena  that  can  be  represented  by 
nouns. 


Object  Class 

Pr o  per  t  i  e  s 
Property  Value  Set 

Fact 


A  group  of  objects  formed  by 
general i zation . 

Characteristics  of  objects. 

The  collection  of  values  that  a  given 
property  may  have. 

The  intersection  of  a  given  object 
with  a  given  property  value  set. 


Association 


A  connection  of  objects  of  the  same  or 
d i f ferent  classes. 


Table  VIII  presents  the  enterprise  object  classes, 
objects  and  object  descriptions.  A  list  of  examples  of 
computer  assets  is  provided  by  OPNAVINST  5239. 1  A. 

2 .  BACHMAN  D i a  gram 

The  BACHMAN  diagram  is  one  technique  that  can  bp 
used  to  specify  the  data  relationships  of  an  enterprise.  The 
circles  or  bubbles  represent  objects  or  entities  and  the 
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that  represents  the  entire  hierarchy.  Succeeding  levels 
contain  blocks  that  represent  various  categories  of 
information  that  may  be  viewed  as  a  subset  of  blocks  further 
up  the  tree.  At  the  lowest  level.  the  diagram  shows 
individual  data  entities.  [Ref.  26] 

D.  THE  ENTERPRISE  MODEL 

The  enterprise  model  results  in  identification  of  the 
data  items  and  the  data  relationships  in  the  enterprise. 
This  procedure  provides  a  starting  point  in  the  design  and 
data  analysis  process.  To  begin,  it  is  necessary  to  define 
primitives  in  the  real  world.  These  real  world  primitives 
will  be  associated  with  conceptual  primitives  in  the  logical 
database  design  phase.  These  real  world  primitives  are 
defined  in  Table  VII. 

1.  Defining  Oata  Elements 


Thp  foundations  of  data  modeling  begin  with 
identification  and  understanding  of  fundamental  structures  or 
primitives  in  the  real  world. 


T  h  p  next 

step  is 

to  identify 

the  elements 

o  f 

the 

enterprise  in 

terms  of 

developing  a 

representation 

o  f 

the 

enterprise.  Th;s  is  an  iterative  process  as  is  much  of  the 
database  design  process.  The  results  of  this 
iterat;on  w 1  1  merely  provide  a  starting  point  to  work  from. 
Throughout  the  design  process  and  even  after  the  system  is 
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Figure  3  3  System  Function  Hierarchy  Chart  (cont'd) 


perform 

risk 

assessment 
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Figure  3  3  System  Function  Hierarchy  Chart 


the  enterprise.  Two  methods  that  will  be  covered  in  this 
thesis  are  the  systems  function  hierarchy  chart  and  the 
BACHMAN  diagram. 


TABLE  VI 

Annual  Loss  Expectancy  Computation 
i  =  Impact  Value  Rating 
f  =  Successful  Attack  Frequency  Rating 

For  Impact .  I  =  1 0  i 

For  Frequency  F  =  10f/3000 

LOSS  =  IMPACT  (I)  X  FREQUENCY  OF  OCCURENCE  ( f) 


The  systems  functions  hierarchy  chart  is  a  re pre sen ta t  ion 
of  the  logical  relationship  among  individual  elements  of 
data.  This  information  structure  is  the  blueprint  for 
defining  organization.  metnods  of  access.  degree  of 
associativity.  and  processing  alternatives  for  information. 
This  information  structure  can  have  a  significant  impact  on 
data  design  requirements  and  therefore  must  represent  the 
hierarchy  of  data  in  a  readable.  unambiguous  manner.  Figure 
3.3  shows  the  system  functions  hierarchy  chart  for  a  computer 
risk  assessment  database.  At  the  top  level  is  a  s’:ngle  block 
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selects  which  countermeasur es  to  implement  and  in  what 
priority.  Priority  is  determined  based  on  return  on 
investment.  Countermeasures  that  yield  the  highest  return  on 
investment  are  implemented  first.  As  each  additional 
countermeasure  is  implemented,  it  will  affect  the  overall  ADP 
security  posture  and  ALE. 

This  procedure  involves  taking  the  threats  with  the 
highest  potential  for  damage.  identifing  a  countermeasure 
that  could  significantly  reduce  the  vulnerability  which  these 
threats  exploit.  and  then  preparing  an  additional 
countermeasure  evaluation  worksheet. 

Data  items  include  return  on  investment.  annual  cost, 
original  ALE  saving,  and  countermeasures. 

Step  five  involves  the  accreditation  process.  Pending 
implementation  of  all  countermeasures.  the  designated 
approving  authority  ( DA  A )  will  grant  the  accreditation  and 
issue  interim  authority  to  operate.  or  order  operations  to 
cease.  See  Appendix  B  for  more  information  about  the 
accreditation  process. 

A  detailed  discussion  of  tnese  procedures  can  be  found 
in  OPNAV  INST  523  9  .  1  A. 

C.  THE  SYSTEMS  FUNCTION  HIERARCHY  CHART 

The  third  step  of  the  user  requirements  analysis  pnase  1 s 
specification.  There  are  several  methods  available  tnat  can 
be  used  to  specify  the  structure  and  flow  of  information  1  n 
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TABLE  V 

Threats  and  their  Impacts 
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The  procedure  involves  identifying  the  threat  that  could 
cause  the  impact  indicated  on  the  Asset  Valuation  Worksheet 
for  each  asset. 


TABLE  IV 

Successful  Attack  Frequency  Rating 


Frequency  Rating 

Once  in  300  years  1 
Once  in  30  years  2 
Once  in  3  years  3 
Once  every  4  months  or  3  times  a  year  4 
Once  a  week  or  52  times  a  year  5 
Once  a  day  or  365  times  a  year  6 
OncP  every  2  hours  7 
Once  every  15  minutes  8 


Step  three,  of  Figure  3.1.  involves  computation  of  the 
annual  loss  expectancy  values  (ALE).  The  impact  dollar  value 
ratings  and  the  successful  attack  frequency  ratings  are 
used  to  produce  the  annual  loss  expectancy  value  for  each  of 
the  four  impact  areas.  This  step  provides  a  quantitative 
figure  for  each  impact  area  and  also  the  total  ALE  for  the 
activity.  Table  VI  shows  annual  loss  expectancy 
computation.  Samples  of  the  ALE  computation  worksheet  and 
risk  assessment  matrix  are  enclosed  in  Appendix  A. 

Step  four.  evaluation  and  selection  of  additional 


c o un te rmea s ure s .  considers  the  evaluated  countermeasures  and 
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9. 

What  are  the  security  risks 
equipement? 

to 

our 

computer 

10. 

What  are  our  top  priorities 
security  vulnerability? 

r el  at 

i  n  g 

to 

asset 

11  . 

Where  should  NPS  concentrate 

strengthen  security? 

i  t  S 

effort 

to 

This 

is  just  a  sampling  of  questions 

that 

could  be 

asked  . 

B.  USER  REQUIREMENTS 

As 

previously  discussed,  the  user 

must 

be 

able 

to  keep 

an  up-to-date  inventory  of  all  NPS  computer  assets.  The 
primary  objective  of  the  proposed  database  system  is  to 
facilitate  risk  assessment.  However,  another  application, 
closely  related  to  the  risk  assessment  objective  is  that  of 
computer  asset  accountability  for  the  purpose  of  control, 
in  the  sense  of  efficient  and  effective  utilization. 
Therefore.  user  requirements  for  a  dual  purpose  system  w1'!! 
addressed  . 

The  requirements  for  step  one.  of  methodology  I.  in 
Figure  3.1  of  the  risk  assessment  procedure  have  already 
been  defined  in  Chapter  I.  The  remaining  four  steps  should 
also  be  addressed  during  the  user  requirments 
analysis  phase.  Oata  in  all  five  steps  is  closely  linked 
together.  In  step  two.  Threat  and  Vulnerability  Evaluation, 
each  asset  is  analysed  in  terms  of  every  threat  it  is  subject 
to  and  the  probability  of  occurance  of  each  threat.  Tables 
IV  and  V  provide  lists  of  t  '■eat  frequency  ratings  and 
examples  of  generally  recognized  threats  and  their  impacts. 
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IV.  LOGICAL  DATABASE  DESIGN 


A.  PROCEDURE 

The  objective  of  the  logical  design  phase  in  the 


relational  database  system  development  process  (Figure  2.1). 


is  to  specify  the  logical 

format 

o  f 

the 

database. 

This 

involves  identifying  the 

record  s 

to 

be 

ma i n ta i ned  , 

the 

contents  of  each  record. 

and  the 

relationsh 

ips  between 

the 

records.  The  resulting  design  is  called  the  logical  schema. 

The  logical  design  phase  generally  involves  five  design 
tasks. 

1.  The  first  task  is  identification  of  the  data  to  be 
stored  in  the  database.  This  step  is  accomplished  by 
processing  the  data  from  the  data  dictionary  and 
screening  out  information  that  will  not  be 
incorporated  into  the  database,  i.e..  descriptions  of 
reports,  serins .  and  input  documents. 

2.  Next,  it  is  necessary  to  standardize  the  terms  used 
to  name  data.  The  failure  to  identify  synonyms  and 
aliases  can  severly  degrade  performance  of  a 
database.  Worst  of  all.  it  can  result  in 
misinformation.  Maintaining  the  integrity  of  the 
database  is  important  and  it  is  one  big  advantage 
of  database  systems  over  traditional  file  systems,  if 
properly  designed. 

3.  Tne  third  step  is  to  define  records  and 

relationships.  The  process  of  defining  records  and 
relationships  is  largely  intuitive  [Ref.  2  7]. 
Records  are  defined  by  identifying  the  data  items 
they  will  contain.  Important  considerations  during 
this  process  include;  designing  flexible  and 
expandable  records  that  can  evolve  with  the 
enterprise.  designing  effective  record  structures, 
and  avoiding  the  using  implied  data  in  record 
definition. 
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Relationships  during  step  three  are  defined  in 

terms  of  how  the  users  see  them.  The  goal  is  to 

include  all  useful  relationships  in  the  logical 
schema.  That  is.  specify  all  enterprise  relationships 
that  are  needed  by  the  user  in  practice. 

4 •  The  fourth  step  in  logical  database  design  is  to 
define  database  processing.  This  requires  analysis 
of  how  the  database  is  manipulated  to  produce 

required  results.  This  can  be  accomplished  by  using 
a  method  called  transform  analysis. 

5.  The  final  step  is  design  review.  The  purpose  of 

review  is  to  identify  problems  with  the  design.  At 
this  point  a  decision  on  whether  to  continue  or  not 
has  to  be  made.  If  the  logical  design  is  approved, 
the  problems  are  corrected  and  the  project  proceeds 
to  the  physical  design  phase. 

Now  it  is  time  to  begin  the  logical  design  phase  wh'ch 
will  be  developed  based  on  information  obtained  from  the  user 
requirements  analysis  phase.  The  next  section  begins  with  a 
brief  discussion  of  the  Semantic  Data  Model  which  will  be 
used  during  the  logical  design  phase.  The  spec;fic  Semantic 
Data  Model  that  will  be  used  is  the  E n t i t y - R e 1  a t i o n s h i p 
Model  . 


B.  SEMANTIC  MODELING 

There  are  several  database  models  a  *  a  •  1  i  r  1  e  »or  t  r  e 

analysis  and  structure  of  data.  However.  t  n  e  s  to;.;«1s  i  r  e 

generally  not  suited  to  handle  both  logical  an:  ; .  *  y  ■  r, 

design  problems.  The  relational  model  can  be  uspC  ten  re'' 

phases  of  the  design  process.  Out  ’*  '  •>  not  recommended. 

There  are  several  drawbacks  to  t  n p  use  of  the  relational 
model  for  logical  database  d  e  s ' g  n .  It  ' s  *  o  o  detailed  to  be 
tne  initial  stages  of  tes'gn.  ;  •  : 


used  in 


1  a  c  x  s  the 


semantic  structure  to  make  unambiguous  cno:ces  ;n 
enterprises  [Ref.  28].  The  relational  model  empnas’^es 
functional  dependences  for  defining  the  se:nant;c  nature  jf 
data.  This  process  is  usually  too  complicated  during  tne 
initial  stages  of  database  design. 

Semantic  models  are  one  way  to  integrate  the  relational 
modPl  into  the  systems  development. 

The  goal  is  to  provide  abstractions  that  naturally  adapt 
to  the  way  that  users  describe  enterprises  [Ref.  29].  The 
semantic  model  is  used  to  identify  the  essential  enterprise 
constructs  and  then  is  modified  by  applying  relational 
criteria.  The  semantic  model  uses  similar  abstractions 
for  defining.  naming.  and  classifying  object  sets  and 
associations  as  listed  in  Table  IX. 

There  are  as  many  different  semantic  models  as  there  are 
varieties  of  ways  to  represent  modeling  abstractions.  One 
well  known  exa~olp  is  the  En t i t y Re  1  a t i o n s h i p  Model. 

C.  THE  ENTITY-RELATIONSHIP  MODEL 

Thp  entity-relationship  model  is  based  on  three  main 
semantic  concepts:  entities,  relationships,  and  attributes. 
T  n  p  enterprise  must  be  described  in  these  three  terms.  See 
Table  X  for  a  description  of  these  three  terms.  Entities 
d  p  s  c  r  ;  b  e  things  in  the  enterprise  whicn  in  turn  are 
described  by  attributes.  Entities  can  also  interact  with  one 
a n c  r  in  any  number  of  relationsnips.  [Ref.  30] 
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TABLE  IX 


Tabular  inscription  of  Enterprise 


OBJECT  CLASS 

PROPERTIES 

HARDWARE 

TYPE 

NAME 

MANUFACTURER 

COST 

DATE  ACQUIRED 
OWNER 

SOFTWARE 

TYPE 

NAME 

MANUFACTURER 

COST 

DATE  ACQUIRED 
OWNER 

COMMUNICATIONS 

TYPE 

NAME 

MANUFACTURER 

COST 

DATE  ACQUIRED 
OWNER 

OWNER 

NAME 

ADDRESS 

PHONE  NUMBER 

CONFIGURATION 

NUMBER 

OWNER 

LOCATION 

SUPPLIER 

NAME 

ADDRESS 

PHONE  NUMBER 

FUND 


TYPE 

NUMBER 

SPONSER 


TABLE  X 


Terminology 

1 .  Entities  -  d  i  st  ic  t  objects  within  a  user  enterprise 

2.  Relationships  -  meaningful  interactions  between  objects 

3.  Attributes  -  describe  the  entities  and  relationships 


Entities  and  relationships  are  organized  into  sets  or 
classes.  Entities  or  relationships  in  a  set  have  the  same 
attributes.  These  sets  all  have  unique  names. 

1.  Entity-Relationship  Diagram 

Entities  and  Relationships  are  represented 
diagramatically  with  the  entity-relationship  diagram.  Entity 
sets  are  represented  by  rectangular  boxes  and  relationships 
are  represented  by  d i amond - sha ped  boxes.  The  relationship 
boxes  are  joined  to  the  entity  boxes  that  participate  in  the 
relationship. 

Figure  4.1  shows  the  entity-relationship  diagram  for  the 
complete  conceptual  risk  assessment  database  system.  The 
entity-relationship  diagram  for  the  control  and  asset 
identification  view  of  the  database  is  shown  in  Figure  4.2. 
This  view  was  constructed  using  the  data  element  information 
and  data  relationships  developed  during  the  data  analysis 
stage. 
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Enitiy -Relationship  Diagram  of  Asset  Identification  View  of  Risk  Assessment  Database  System 

Figure  4.2 


Table  XI  shows  the  attributes  for  each  entity  and 
relationship  type.  Attributes  describe  some  aspect  of  an 
entity  or  relationship.  Some  attributes  are  also  used  to 
uniquely  identify  each  entity  occurence.  One  or  more 
attributes  can  be  used  to  identify  an  occurence.  These 
attributes  are  called  key  attributes.  Relationships  must  be 
uniquely  identified  in  the  same  way.  Relationships  are 
normally  identified  by  more  than  one  attribute.  Tentative 
keys  are  indicated  by  underlining. 

2 .  Logical  Schema 

The  logical  schema  is  composed  of  the  records  to  be 
maintained,  their  contents,  and  the  relationships  among  those 
records  specified.  In  the  entity-relationship  diagram, 
entities  and  r e 1  a t i on s h i ps  become  records.  The  entity- 
relationship  diagram  shows  the  r e 1  a t i o n sh i ps  between  records, 
however.  the  records  and  their  contents  have  not  yet  been 
i  d  e  n  t '  f  i  e  d  . 

The  process  of  logical  record  structure  involves  making 
each  entity  and  relationship  in  the  entity-relationship 
diagram  a  separate  record.  The  attributes  associated  with 
each  entity  and  relationship  then  become  fields. 

As  the  requirements  are  evaluated  and  the  design 
progresses.  constraints  on  data  items  will  be  identified. 
Constraints  are  limitations  on  the  values  that  database  data 
can  have.  There  are  three  common  types  of  constraints: 
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TABLE  XI 


Entity-Relationship  Attribute  List 


EQUIPMENT 

EQUIPMENT-NUMBER 

EQUIPMENT-T7TO 

MANUFACTURER 

EQUIPMENT-NAME 

COST 

DATE-ACQUIRED 


CUST00Y-0F 

EjQU  I  P  M  E  NT  -  NUMBER 

ownFr-numbTr 
CUSTODY -NUMBER 


OWNER 


OWNER -NUMBER 

owneE-nW 

OWNER-ADDRESS 

OWNER-PHONE 


PART-OF 

CUSTODY-NUMBER 
C  0  NTTOUITOTTOI  -  N  U  M  B  E  R 


CONFIGURATION 

CONFIGURATION -NUMBER 
OWNER -NUMBtR 
CONFIGURATION-LOCATION 
CONFIGURATION-ADDRESS 
CONFIGURATION-PHONE 
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TABLE  XI  (cont'd) 

Enitity-Relat'onsrnp  Attribute  List 


SUPPLIER -NUMBER 

e^ui'PmTnT-numUr 

RUTPMFNT-mrF" 


SUPPLIER 

SUPPLIER-NUMBER 

SUPPLTFff-TIITTr 

SUPPLIER-AOORESS 

SUPPLIER-PHONE 


E-F 


EQUIPMENT-NUMBER 
T  U  N  0  - N  U MlFE 


FUND 


FUN D^N UMBER 

FUND-TTPf 

SPONSER 


6 


field  constraints.  inter-record  constraints  and 
intra-record  constraints.  Field  constraints  limit  the  values 
that  a  given  data  item  can  have.  Interrecord  constraints 
limit  values  between  fields  in  different  records. 
Intrarecord  constraints  limit  values  between  fields  within  a 
given  record.  [Ref.  31] 

See  Table  XII  for  record  specifications  of  the  logical 
schema. 

D.  PR03LEMS  WITH  SEMANTIC  MODELING 

When  constructing  the  entity-relationship  model.  the 
design  should  arguably  consider  the  correspondence  between 
the  semantic  model  to  normal  relations.  Hovever.  imposing 
such  constraints  on  the  semantic  process  can  restrict  the 
naturalness  of  the  model,  which  is  the  reason  it  is  used. 

Semantic  mooels  do  not  possess  the  criteria 
necessary  to  prevent  anomalies  and  eliminate  redundancies. 
This  role  is  reserved  for  the  relational  model  in  the  next 
stage  . 

Another  problem  is  the  treatment  of  relationships  in  the 
entity-relationship  model.  The  e n t  i  t y -r e 1  a t i o n s h  i  p  model  can 
easily  accomodate  one-to-one  or  many-to-many  relationships. 
Additionally.  the  entity-relationship  model  can  be  defined 
on  a  single  entity-type  as  well  as  on  threp  or  morp  types. 


However,  most  DBMS's 


are  not  as  flexible. 


TABLE  XII 


Record  S pe c i  f > c a t i o n  for  Logical  Schema 


Field 

Description 

EQUIPMENT 

Record 

E  qu i pment-number 

E  qu i pmen  t- 1  y pe 
Manufacturer 

Equ ' pmen  t-n  ame 

Cost 

Date-acquired 

Numeric.  6  decimal  digits 
Alphanumeric.  40  characters 
Alphabetic.  30  characters 
Alphanumeric.  30  characters 
Alphanumeric.  10  cnaracters 
Format:  YYMMDD 

CUST0DY-0F 

Record 

Equipment-number 

Owner-number 

Cu  stod  y-number 

Numeric.  6  decimal  digits 
Format :  999 : 9  9  :  9999 

Numeric.  8  decimal  digits 

OWNER  Record 

Owner-number 

Owner-name 

Owner-address 

Own  er -  phone 

Format:  999:99:9999 

Alphabetic.  30  cnaracters 

A  1 phanumer  i  c  .  40  characters 
Format:  (999)999-9999 

PART-OF  Record 


Custody-numoer 
Conf iguration-number 


Numeric.  10  decimal  digits 
Numeric.  5  decimal  digits 


TABLE  XII  ( cont ' d ) 

Fee  or d  Specification  for  Logical  Schema 


Field 

Description 

CONFIGURATION 

Record 

Configuration-numDer 

Owner-number 

Configuration-location 

Conf  igurat  ion -address 

Locat  ;on~phone 

Numeric.  5  decimal  digits 
Format:  999-99-9999 
Alphanumeric.  30  characters 
Alphanumeric.  30  characters 
Format:  (999)999-9999 

E-S  Record 

Suppl  ier-numper 

E  q  u i pment-number 

Price 

Numeric.  3  decimal  digits 
Numeric.  6  decimal  digits 

A  1 p na n ume r i c  .  10  characters 

SUPPLIER  Record 

Suppl  ier-number 

Suppl  ’:er-name 

Suppl i er-address 

Suppl  '°r~phone 

Numeric.  8  decimal  digits 
Alpnanumeric.  30  characters 
Alphanumeric.  30  characters 
Format:  (999)999-9999 

E  -  F  Record 

Equ’  pment-number 

Fund-number 

Numeric.  6  decimal  digits 
Numeric.  4  decimal  digits 

FUND  Record 


Fund-number 
Fund -type 
S  p  0  n  5  9  r 


Numeric.  4  decimal  digits 
Alphabetic,  30  characters 
Alphanumeric.  30  cnaroctDrs 


TABLE  XV 


Relation  Definitions 


1.  EQUIPMENT  (  E  :  N  U  M  .  E : T  Y  PE  .  E  :  M  F  G  .  E : N  A  M  E  .  E:C0ST. 

rriyiFACQ) 

2.  E-0  ( E : N U M .  0 : NUM  .  C:NUM) 

3.  OWNER  (0 : NUM .  0  :  L  N  A  M  E  .  0 : FN AHE  .  OrSTRET.  0  :  C  I  T  Y  . 

0  :  STl’TE  .  O-.ZIP.  0  :  PHONE  ) 

4.  0-C  (  C  :  N U M  .  CO^NUt!) 

5.  CONFIGURATION  (CO:NUM.  0:NUM.  CO:LOC.  CO:STRET. 

CO.-CITY.  CO.-STATE.  CO.-ZIP.  CO  :  PHONE  ) 

6.  E-S  ( S : NUN  .  E : N U  M  .  PRICE) 

7.  SUPPLIER  ( S : N  U  M  .  S  :  NAME  .  S  :  STRE  T  .  SrCITY.  S  :  STATE  . 

TT7TP .  S: PHONE) 

3.  E-F  ( E : N U M  .  F : NUM ) 

9.  FUND  ( F : NUM  .  F  :  TYPE  .  F  :  S  P  0  N  S  R  ) 
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Transformations  are  important  if  them  is  a  need  to 
transform  data  between  the  outside  world  and  the  database. 
Access  privilege  defines  which  users  are  allowed  access  to 
which  data  elements.  Finally.  file  management  information 
may  be  contained  in  tne  schema.  File  management  concerns 
matters  such  as  control  indexing.  transposition.  control  of 
integrity,  archiving,  and  erasure  cycles. 

The  relation  definitions  of  the  risk  analysis  project  are 
snown  in  Table  XV.  Attribute  domains  and  domain  definitions 
are  listed  in  Tables  XVI  and  XVII. 

E.  OATA  MANIPULATION 

In  relational  databases.  relations  are  viewed  as 
collections  of  records  (tuples),  and  relational  operations 
apply  to  entire  relations.  At  the  most  elementary  level, 
there  are  three  operations  that  need  to  be  discussed: 
project' on.  select 'on.  and  join.  [Ref.  41] 

The  first  relational  operation.  projection.  produces  a 
new  relation  tnat  contains  only  the  columns  (attributes)  from 
the  original  relation  that  are  specified  in  the  projection 
request.  It  is  important  to  note  that  this  operation  will 
eliminate  any  duplicate  tuples  that  may  naturally  occur. 

Tne  selection  operation  will  produce  only  tne  rows 
(tuples)  from  the  original  relation  tnat  satisfy  a  certain 
cond':t''on  or  conditions.  The  results  of  both  projection  and 


The  complete  data  element  definition  for  the  data  element 


E:NUM  is  illustrated  in  Figure  5.2. 


NAME 

E  :  NUM 

TYPE 

NUMERIC 

DOMAIN 

EQUIPMENT_ IDENTIFIERS 

LENGTH 

(6) 

Figure  5.2  Data  Definition  of  E  :  N  U  M 


Qualitative  characteristics  of  data  elements  are  used  to 
provide  additional  semantic  information.  These  include 
title.  unit  specification,  essential  data,  undefined  values, 
transformations,  access  privilege,  and  file  management. 

A  title  is  sometimes  used  to  provide  a  more  detailed 
description  of  the  data  element.  Unit  specification  is  used 
to  ensure  standardization  when  units  of  measure  are  involved. 
Essential  data  refers  to  whether  the  data  element  is  required 
or  is  optional  in  a  record.  Undefined  values  provide 
information  about  whether  data  can  be  missing  or  left 
undefined.  Programs  that  operate  on  the  database  must  be 
able  to  recognize  this  fact. 


For  example.  the  name  for  the  data  element.  equipment 
identi f ier  ,  is  E : NUM  . 

A  type  specification  is  usually  associated  with  each 
data  element  name.  The  type  specification  limits  the  values 
to  be  associated  with  the  data-element  names  to  a  specified 
domain,  simplifies  processing  by  implying  the  category  of 
legal  operations  to  be  used  in  the  t r a n s f o rma t i o n  of  data  and 
it  provides  specifications  for  encoding  of  the  data  values. 
[Ref.  40]  Most  computer  languages  provide  a  small  number  of 
general  choices,  such  as.  CHARACTER,  DECIMAL.  BINARY  INTEGER. 
BINARY  FIXED  POINT  NUMBER.  and  REFERENCE  just  to  name  a  few. 
The  data  element  E:NUM  is  specified  as  being  NUMERIC. 

Domain  defines  the  range  of  allowed  values  for  a  data 
element.  It  can  be  valuable  by  keeping  improper  elements  out 
of  the  database.  For  each  data  element  then,  there  is  a 
domain  for  which  there  is  a  corresponding  domain  definition. 
The  attribute  domain  for  the  data  element  E:NUM  is 
EQU I P_I DE NT  I F I ERS  which  is  defined  as  NUMERIC  999999.  Each 
nine  in  this  example  represents  a  space  for  a  numeric 
character.  This  number  represents  the  plant  account  number 
when  it  is  available. 

Length  can  be  specified  as  either  fixed  or  variable. 
Another  way  to  specify  the  length  of  the  data  element  E:NUM 
is:  E:NUM  NUMERIC  (6).  where  the  number  6  specifies  the 
length  of  the  data  element. 


further.  is  necessary  to  generate  the  processing  programs 
that  deal  with  the  database. 

Data  definitions  and  relationships  are  taken  from  the 
results  of  the  previous  design  phases.  Any  new  procedures 
that  are  identified  at  this  stage  are  also  included  in  the 
design. 

An  essential  part  of  defining  data  elements  is  that  the 
data  elements  must  be  defined  in  terms  of  programming 
language  specifications.  The  process  involves  assigning  a 
name  and  defining  specific  c har ac ter i s t i c s  of  data  elements. 
This  specification  is  known  as  the  data  type. 

There  are  both  quantitative  and  qualitative 
characteristics  of  data  elements.  Quantitative 
characteristics  include  name,  type,  domain  and  length. 

Names  have  been  used  during  the  ent’re  database 
development  process  to  define  attributes  in  records  and 
relations.  The  name  given  to  a  data  element  is  usually 
controlled  by  stra ight- for  ward  rules  and  depends  on  the 
programming  language  used.  These  rules  generally  allow  for 
a  short.  variable-length  string  of  alphabetic  and  numeric 
characters.  the  first  character  being  restricted  to  be 
alphabetic.  Names  used  in  files  and  databases  are  generally 
global.  In  a  database.  the  name  of  a  data  element  s 
affected  only  by  structural  scope,  defined  as  the  database  or 
relation  that  contains  the  data  element.  [Ref.  39J 


DK/NF.  The  second  criteria  is  to  design  relation 

independence  to  support  error  free  operation  of  the  database 
system.  The  third  criteria  is  to  create  a  relational  design 
that  is  easy  to  use.  This  involves  trying  to  structure  the 
relations  so  that  they  are  familiar  and  seem  natural  to 
users. 

Often.  these  three  design  criteria  conflict  w’tn 
each  other.  It  is  the  responsibility  of  the  designer  to 
assess  priorities  and  make  the  best  possible  comprom’sp 
because  of  the  re qu i r emen t s .  There  are  no  rules  for  t 
questions  of  priority.  [Ref.  37] 

0.  THE  RELATIONAL  SCHEMA 

To  translate  a  model  into  an  operational  system, 
the  model  has  to  be  described  in  a  form  which  lends 
itself  to  implementation.  This  initial  model  is  called  the 
relational  schema  and  the  language  used  to  describe  it  is 
called  the  schema  language. 

One  objective  of  the  database  system  is  to  systematize 
the  access  to  data  elements.  To  be  able  to  fetch  data 
elements.  irrespective  of  the  file  and  record  structure.  we 
will  have  to  p  ovide  descriptions  which  allow  determination 
of  position  and  type  of  the  data  elements  by  attribute  name 
and  value,  or  by  attribute  relationship.  [Ref.  38] 

This  is  an  impor  mt  element  of  obtaining  a  description 
of  the  database  requ  ir ement s .  Defining  the  data  elements 


A  key  of  a  relation  comprises  one  or  more  attributes 
that  functionally  determine  or  identify  a  tuple.  Because  a 
key  functionally  determines  the  entire  tuple.  it  must  be 
unique.  If  it  were  not  unique,  then  the  entire  tuple  would 
be  duplicated.  and  this  is  not  allowed  by  definition. 
[Ref.  36] 

For  a  relation  to  be  in  second  normal  form.  all  nonkey 
attributes  must  be  dependent  on  all  the  key  attributes.  A 
relation  is  in  third  normal  form  if  it  is  in  second  normal 
form  and  has  no  transitive  dependencies.  Finally,  a  relation 
is  in  Boyce-Codd  normal  form  if  it  is  in  third  normal  form 
and  every  determinant  is  a  candidate  key. 

Even  with  a  relation  in  Boyce-Codd  normal  form,  anomalies 
can  still  arise  from  multivalued  dependency.  Additionally, 
anomalies  can  result  from  joining  two  projections  on  a 
relation.  These  two  anomalies  are  eliminated  by  the  fourth 
and  fifth  normal  forms  respectively.  The  QK/NF  eliminates 
all  modification  anomalies.  A  relation  is  in  DK/NF  if  every 
constraint  on  the  relation  is  a  logical  consequence  of  the 
definition  of  keys  and  domains. 

There  are  three  criteria  that  should  be  used  to  produce 
an  effective  relational  database  design.  They  are  the 
elimination  of  modification  anomalies.  relation  independence 
and  ease  of  use. 

The  first  criteria.  elimination  of  modification 
anomalies.  will  be  achieved  if  the  relation  is  put  into 


The  first,  second,  third  and  Boyce-Codd  normal  forms  all 
address  anomalies  caused  by  inappropriate  functional 
dependencies.  A  functional  dependency  is  a  relationship 
between  attributes.  "Attribute  Y  is  said  to  be  functionally 
dependent  on  attribute  X  if  the  value  of  X  determines  the 
value  of  Y."  [Ref.  33]  Functional  dependencies  are  denoted 
by  the  form.  X  -->  Y.  where  attribute  X  is  called  the 
determinant,  and  Y  is  called  the  dependent  variable. 

Determinants  may  or  may  not  be  unique.  Functionally 
dependent  attributes  need  not  be  unique  either.  Functional 
dependencies  can  involve  groups  of  attributes,  and  one  or 
more  attributes  can  determine  several  attributes. 


TABLE  XIV  [Ref.  35] 

Summary  of  Normal  Forms 

Form 

Defining  Characteristic 

INF 

Any  relation 

2  NF 

All  no-key  attributes  are  dependent  on 
of  the  keys 

all 

3NF 

There  are  no  transitive  dependencies 

BCNF 

Every  determinant  is  a  candidate  key 

4  N  F 

Every  multivalued  dependency  is  a 
functional  dependency 

5  NF 

Join  dependencies  are  satisfied 

OK  /NF 

All  constraints  on  relations  are  logi 
consequences  of  domains  and  keys 

c  a  1 

The  fee  is  dependent  on  the  activity  and  is  the  same  for 
all  students  engaging  in  that  activity.  In  we  deleted  the 
tuple  for  the  first  student.  200-22-1234  in  Figure  5.1.  we 
loose  the  fact  that  student  200-22-1234  is  a  tennis  player. 
However,  we  would  also  loose  the  fact  that  tennis  costs  $50. 
This  is  an  example  of  a  deletion  anomaly.  If  we  wanted  to 
add  an  activity  to  the  relation.  for  example.  racketball. 
which  costs  $55,  we  could  not  do  so  until  a  student  enrolls 
in  that  activity.  This  is  an  example  of  an  insertion 
anomaly.  These  anomalies  can  be  prevented  by  a  process 
called  decomposition  where  a  single  relation  is  broken  down 
into  two  separate  relations.  To  ensure  reliability, 
data  integrity,  and  efficiency.  modification  anomalies 
must  be  eliminated.  Anomalies  can  be  eliminated  by  changing 
the  database  design.  Relations  can  be  independent  or 
interdependent.  Usually.  the  less  i n t erde pend enc y .  the 
better. 

The  problem  of  modification  anomalies  focused  attention 
on  the  form  of  the  relations  that  resulted  in  data  errors. 
The  problem  was  addressed  by  the  concept  of  relational  normal 
forms.  There  are  seven  different  normal  forms,  in 
hierarchical  order  ranging  from  the  First  Normal  Form  (INF), 
which  includes  all  relations,  to  Domain  Key/Normal  Form 
(0K/NF).  in  which  relations  are  free  from  all  modification 
anomalies  regardless  of  their  type.  Table  XIV  shows  the 
seven  different  normal  forms. 
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modification  anomalies.  Two  common  modification  anomalies 
are  insertion  and  deletion  anomalies.  Insertion  anomalies 
result  when  information  is  gained  about  two  different 
entities  with  a  single  insertion.  Deletion  anomalies  result 
when  facts  are  lost  about  two  entities  with  one  deletion. 
Consider  the  ACTIVITY  relation  in  Figure  5.1.  It  has  the 
attributes  STUDENT_ID.  ACTIVITY.  and  FEE.  The  relation 
contains  information  about  what  activity  a  student  engages  in 
and  s  ^  w  much  it  costs. 


RELATION:  ACTIVITY 

S  T  U  D  E  N  T _ I  D 

ACTIVITY 

FEE 

200-22-1234 

TENNIS 

50 

111-23-2345 

SKIING 

100 

752-41-4982 

GOLF 

75 

543-65-3856 

SWIMMING 

60 

Figure  5.1 

Relation  ACTIVITY 
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be  selected  as  the  primary  key.  Keys  are  used  during  the 
design  process  to  avoid  designs  that  have 
undesireable  properties. 

One  reason  data  definition  if  so  important  in  the 
relational  model  is  that  relationships  are  not  represented  by 
explicit  links  as  they  are  in  other  models.  but  are  carried 
in  the  data.  Basic  relational  operations  operate  on  entire 
collections  of  entities  and  relationships  instead  of  dealing 
with  them  individually.  In  using  a  relational  DBMS,  the  user 
specifies  what  is  wanted.  and  the  system  must  decide  how  to 
do  it.  For  this  reason,  relational  systems  appear  simple  and 
easy  to  use.  It  is  also  conceptually  easier  to  implement  a 
relational  system.  However,  a  simple  straight  forward 
approach,  without  an  understanding  of  the  mathematical  theory 
on  which  the  relational  model  is  based,  can  result  in  poor 
per  formanc  e  . 

C.  NORMALIZATION 

The  process  of  no rma 1 i za t i o n  invloves  converting  an 
arbitrary  relational  database  design  to  one  that  avoids 
certain  anomalies.  The  purpose  is  to  produce  a  database 
design  that  can  be  manipulated  in  a  powerful  way  with  a 
simple  collection  of  operations  while  minimizing  data 
anomalies  and  inconsistencies. 

With  some  relations.  changing  data  can  have  unexpected 
and  undesireable  consequences.  These  are  known  as 
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a  two-dimensional  table  called  a  relation  which  is  formally 


defined  as  an  unordered  set  of  ordered  n-tuples.  An  n-tuple 
is  a  set  of  n  values  which  is  like  a  record.  The  values 
within  a  tuple  have  to  be  ordered  because  the  values  do  not 
carry  identifying  labels.  The  columns  correspond  to 
attributes  and  each  row  is  an  occurence.  A  summary  of 
relational  model  terminology  can  be  found  in  Table  XIII. 


TABLE  XIII 

Relational  Model  Terminology 

1.  Relation  -  a  two  dimensional  table  that  has  several 

proper t  ie  s 

2.  Attributes  -  the  columns  of  a  relation 

3.  Tuples  -  the  rows  of  a  relation 

4.  Domain  -  the  set  of  values  that  an  attribute  can  have 


A  relation  cannot  contain  any  duplicate  rows. 
It  is  important  to  note.  however.  that  no  relational  DBMS 
enforces  this  constraint.  The  reason  for  preventing 
preventing  duplicate  rows  is  so  that  one  collection  of 


a  t  tr 

ibutes  will  un 

i  q  u  e  1  y 

identify  a 

tuple 

.  The 

number 

o  f 

attributes  that 

are 

needed .  can 

range 

from 

one 

to 

all 

the  attributes 

i  n 

the  tuple. 

E  a  c  n 

collect 

i  o  n 

o  f 

V.  PHYSICAL  DATABASE  DESIGN 


A.  OBJECTIVE 

Before  starting  the  physical  design  process  it  is 

necessary  to  take  a  look  at  the  system  that  will  be  used  to 
implement  the  database.  One  requirement  of  the  design 

specification  is  that  it  should  be  easily  converted  to  the 
implementation  model.  The  data  design  model  is  dependent  on 

the  DBMS.  In  this  case,  it  was  determined  at  the  outset, 

that  the  database  would  be  processed  by  a  relational  DBMS. 
Therefore.  the  relational  database  model  will  be  used  to 
express  the  design  of  the  database. 

There  are  two  basic  steps  in  the  physical  database 
design  process.  The  first  step  involves  transforming  the 
logical  schema  into  the  particular  data  constructs  to  be  used 
by  the  particular  DBMS  selected.  The  first  step  will 
produce  detailed  specifications  of  the  database  that  will  be 
used  during  database  implementation  to  write  source 
statements  that  define  the  database  structure  to  the  DBMS 
[Ref.  33  J .  The  second  step  is  to  review  the  design  and  to 
modify  it  to  achieve  optimal  performance. 

B.  THE  RELATIONAL  MODEL 

The  relational  database  model  uses  a  single  construct  to 
represent  both  entities  and  relationships.  The  construct  is 


Additionally.  although  the  process  of  defining  entities 
and  relationships  appears  to  be  quite  clear.  the  database 
designer  must  decide  how  to  assign  entities  and 
relationships.  It  is  up  to  the  designer  to  establish  the 
importance  of  various  objects  ’:n  the  organization  being 
modeled.  Consequently.  the  design  process  is  not 
determ-'nistic.  Different  designers  can  produce  different 
models  of  the  same  enterprise  and  which  in  turn  produce 
totally  different  results.  [Ref.  32] 
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TABLE  XVI 


Attribute 

1  .  E  :  N  U  M 

2.  E : T  Y  PE 

3.  E : M  F  G 

4.  E : NAME 

5.  E : CO  ST 

6.  E : DATACQ 

7  .  0  :  N  U  M 

3.  C  :  N  U  M 

9.  0 : L  N  A  M  E 
0.  0 : FNAME 

1.  0 : S TRE  T 

2.  0 : C I T  Y 

3.  0:  STATE 

4.  0 : Z I P 

5.  0 : PH  ONE 

6  .  C  0  :  N  U  M 

7.  CO : LOC 

8.  CC  :  STRET 

9.  CO-.CITY 
0.  CO : STATE 
I  .  CO:  Z IP 

2.  C  0 : P  H  C  NE 

3  .  S  :  N  U  M 

4.  PRICE 

5.  S  :  N  A  M  E 

6.  S  :  r TRET 

7.  S : C I T  Y 

3.  S : S  T  A  T  E 
9.  S  :  Z  I  P 
3.  c : P  H  0  N  E 

L  .  F  :  N  U  M 

2.  F  :  TYPE 
3  .  F  :  S  P  0 !  I S  R 


Attribute  Domains 


Domain 


EQUIP  IDENTIFIERS 

EQUIP~ TYPES 

MFG_NAMES 

E  Q  U I P_  NAMES 

PRICES 

DATES 


OWNER_ IDENTIFIERS 
CUSTODY_IDENT  IFIERS 

L_  N  A  M  E  S 
F  NAMES 

sTreet^addresses 

CITY  NAMES 
STATr  NAMES 
Z IP_CUDES 
PHONE_NUMBERS 

C  C-  N  F  I  G _ IDENTIFIERS 

LOCATION  NAMES 
STREET  ADD.' ESSES 
CITY  NAMES 
S  TATli_N  A  ME  S 

Z I P _ CODE S 

PHONZ_N UMBERS 

SUPPLIER  IDENTIFIERS 
PRICES 


SUPPL IE R_ NAMES 
STREET_ADDRESSES 
CITY  NAMES 
ST  AT E_ NAMES 
Z I P_C  0  D  E  S 
PHONE_NUMBERS 

FUN  D_ IDENTIFIERS 

FUND_TYPES 
SPONSER  NAMES 
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TABLE  XVII 


Domain  Definitions 

Domain  Name  Format  and  Meaning 


1.  C I T  Y_N  A  M  E  S  CHAR  (25) 

2.  CONFIG _ I  DENT  IF IERS  numeric  9999  9  ;  uniquely 

identifies  each  configuration 

3.  CUST0DY_ IDENTIFIERS  numeric  9999999999;  identify 

specific  ownership  of  each  piece 
e  qu i pmen  t 

4.  DATES  numeric  YYMMDD 

5.  E Q U I P_ I DE NT  I F I E R S  numeric  999999  ;  uniquely 

identifies  each  piece  of 
e  q  u i pme  n  t 

6.  EQUIP_ NAMES  CHAR  (30);  standard  commercial 

nomenclature 

7.  E  0  U I P_T  Y  PE  S  CHAR  (40);  must  fit  one  of  the 

object  categories  listed  is 
Table  VII 

3.  F_NAMES  CHAR  (10);  first  names  of  people 

9.  FUN D_ IDENTIFIERS  numeric  9999;  uniquely 

identifies  each  fund 

10.  FUN D_ TYPES  CHAR  (30);  identifies  fund  as 

being  research.  0PM.  0&MN 

11.  L0CAT ION _ NAMES  CHAR  (30);  identifies  location 

of  configuration  beyond  street 
address  -  building  name  and 
room .  home 

12.  L_NAMES  CHAR  (20);  last  names  of  people 

13.  MFG  NAMES  CHAR  (30);  names  of  manufacturers 
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TABLE  XVII  (cont'd) 
Domain  Definitions 


Domain  Name 


Format  and  Meaning 


14. 

0WNER_ IDENTIFIERS 

999:99:9999;  social  security 
numbers  are  used  to  uniquely 
identify  individual  owners 

15. 

PH0NE_NUMBERS 

(999)999-9999 

16. 

PRICES 

numeric  999999999.99 

17. 

STATE_NAMES 

CHAR  (2);  two  character  state 
abreviations 

18. 

ST  RE  E  T_A  DDRE  S  SE  S 

CHAR  (30) 

19. 

SUPPLIER_ IDENTIFIER 

numeric  99999999;  uniquely 
identifies  equioment  suppliers 

20. 

SUPPLIER _ NAMES 

CHAR  (30);  names  of  equipment 
s  u  p  p  1  i  e  r  s 

21  . 

Z  I  P_C  0  DE  S 

numeric  99999;  five  digit  postal 
zip  code 

selection  are  also  relations  and  therefore  can  be  used  to 
produce  any  desired  subset  of  an  original  relation. 

The  join  relational  operation  is  used  to  combine  data 
from  two  relations  into  one.  It  produces  a  new  relation  that 
contains  all  the  columns  from  both  of  its  input  relations. 
Tuples  from  the  two  input  relations  are  combined  by  looking 
for  matching  values  in  a  specified  common  attribute  of  each. 

Most  DBMS's,  however.  enable  users  to  handle  data 
manipulation  at  a  higher  level  than  the  examples  just 
described.  DBMS’s  generally  use  English-like  syntax  and  tend 
to  hide  the  actual  structure  of  the  database  from  the  user. 

To  process  relations  with  a  computer,  it  is 
necessary  to  have  a  clear.  unambiguous  language  for 
expressing  what  you  want  to  do.  There  are  four  different 
strategies  for  relational  data  manipulation:  relational 
algebra.  relational  calculus.  tr an s f o rm-or i en ted  ,  and 
graphic.  Since  many  D8MS  products  use  tr an s f o rm- o r i e n t ed 
relational  language,  this  language  will  be  emphasized. 

Tr an s f o rm- o r  i  e n t ed  languages  are  a  class  of 
non-procedural  languages  that  use  relations  to  transform 
input  data  into  desired  outputs.  These  languages  provide 
easy-to-use  structures  for  expressing  what  is  desired  in 
terms  of  what  ’:s  known.  [Ref.  42] 

An  example  of  a  relational  Database  Manipulation 
Language  ( D ML )  which  ’s  transform-oriented  is  SQL.  SQL 
stands  for  Structured  Query  Language.  The  basic  construct  of 


SQL  is  a  mapping,  whose  syntax  takes  the  for 

SELECT  <attribute> 

FROM  <relation> 

WHERE  <condition  clau$e> 

The  simplest  condition  clause  appears  as: 

<attribute>  <binary  operator>  <value> 

The  binary  operators  include  =  .  NEQ.  >_.  <_.  >.  <. 

The  output  from  a  mapping  is  a  set  of  values.  The 
values  are  chosen  by  selecting  each  relation  row  that 
satisfies  the  condition  clause.  The  value  of  the  attribute 
of  each  such  selected  row  becomes  part  of  the  output. 
[Ref.  43] 

This  chapter  has  presented  some  of  the  important  aspects 
of  the  physical  database  design  phase.  It  stressed  the  fact 
that  all  relational  database  designs  are  not  equal.  Some 
relational  schemas  suffer  modification  anomalies,  some  have 
unacceptable  dependencies  among  relations.  and  some  are 
poorly  suited  to  users.  The  criteria  for  good  relational 
designs  are  reduction  or  elimination  of  modification 
anomalies.  minimization  of  interrelation  constraints.  and 
ease  of  use.  An  initial  relational  database  design  has  been 
created  for  asset  identification  and  valuation  for  risk 
assessment  at  NPS. 
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VI.  IMPLEMENTATION  CONSIDERATIONS 


A.  DATABASE  MANAGEMENT  SYSTEMS 

The  database  management  system  (DBMS)  is  a  specialized 
piece  of  software  that  is  used  to  implement  a  database.  The 
DBMS  serves  as  an  interface  between  the  data  and  the  user. 
How  the  database  management  system  interfaces  with  the 
overall  system  is  illustrated  in  Figure  6.1.  Users  and 
their  application  programs  make  requests  to  the  DBMS.  If 
the  request  is  valid.  the  D3MS  takes  responsibility  for 
performing  the  necessary  database  manipulations.  However,  it 
is  not  able  to  do  this  directly  and  must  invoke  the  file 
handling  capabilites  of  the  operating  system  to  read  or  write 
data.  This  interaction  with  the  system  introduces  additional 
overhead.  [Ref.  44]  In  currently  available  systems 
DBMSs  appear  to  the  operating  system  as  just  another  user 
program . 

There  are  two  primary  functions  of  a  DBMS.  First.  it 
assists  users  in  manipulating  the  database,  and  secondly,  it 
protects  the  database  from  the  users.  Assistance  is  provided 
to  users  by  program  modules  that  perform  standard  functions 
such  as  data  retieval  or  modification.  Additional  assistance 
is  provided  by  program  modules  that  perform  functions  cn  the 
database  without  the  need  for  any  programs  to  be  written  at 
all.  Examples  include  query  processors  and  report 
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user/ap  plication 
program 


database 

management 

system 

(DBMS) 

operating 

system 

(OS) 


generators.  The  use  of  standard  system  modules  greatly 
enhances  database  system  operations.  It  reduces  the  amount 
of  work  that  must  be  done  to  implement  new  applications  and 
also  increases  the  reliability  of  applications.  The  DBMS 
provides  a  natural  interface  for  user  data.  The  interface 
must  be  independent  of  any  physical  storage  structures. 
Finally,  the  DBMS  should  have  the  ability  to  construct 
different  views  of  the  database.  That  is,  portions  of  the 
database  that  are  irrelevant  to  an  application  can  be  hidden 
from  it.  and  the  structure  of  what  remains  can  be  adjusted  to 
fit  the  application's  specific  requirements  [Ref.  45]. 

The  second  function  of  a  DBMS,  database  protection,  is 
implemented  primarily  through  a  gate-keeping  function  for  the 
DBMS.  All  user  requests  must  be  made  through  the  DBMS.  This 
allows  the  DBMS  to  evaluate  each  request  and  decide  whether 
it  should  proceed.  The  decision  can  be  made  on  both 
authorization  criteria  and  on  integrity  criteria.  A  type  of 
access  control  is  also  implemented  through  defining  views  to 
include  or  exclude  particular  portions  of  the  database. 
[Ref.  46] 

The  above  fundamental  capabilities  of  a  DBMS  required  to 
support  the  database  are  summarized  in  Table  XVIII. 

Two  central  functions  of  DBMS  software  are  to  define  a 
database  and  to  access  the  defined  database.  DBMSs  use 
special  languages  to  define  databases.  After  a  database  is 
designed.  the  database  structures  are  defined  using  the  Data 
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Definition  Language  (DDL).  Software  to  access  databases  is 
classified  into  three  categories  that  coincide  with  three 
levels  of  users.  The  professional  programmer,  who  developes 
programs  for  other  users,  employs  embedded  database  access 
commands  in  a  programming  language.  These  commands  are  known 
as  data  manipulation  language  (DML).  Most  systems  also 
provide  query  languages  for  the  second  level  of  user.  the 
nonprogrammer  user.  A  few  systems  provide  a  natural  language 
interface  for  the  third  level  of  user.  the  casual  user. 
[Ref.  47] 

TABLE  XVIII 

Fundamental  Capabilities  of  DBMS 

1.  Must  provide  a  natural  interface  of  user  data 

2.  The  interface  must  be  independent  of  any  physical 
storage  structures 

3.  Different  users  should  be  able  to  access  the  same 
database,  using  different  views  of  the  database 

4.  Changes  to  the  database  can  be  made  without 
affecting  programs  that  make  no  use  of  the  change 

There  is  a  subtle  difference  between  data  models  and 
their  implementation.  Data  models  are  abstractions  while 
implementations  are  a  software  realization  of  the  data  model 
abstraction.  There  are  a  variety  of  DBMSs,  and  each  s 


•f m p  1  pme n ted  by  different  software  structures.  These  software 
structures  are  called  DBMS  ar c h  i  t ec t ur e s  .  The  software 
components  of  a  DBMS  must  provfde  for  each  of  the  functions 
listed  in  Table  XIX.  The  combination  of  software  components 
is  called  a  database  architecture. 

TABLE  XIX 

Primary  Goals  of  DBMS 

1.  define  the  chosen  database  logical  structures 

2.  define  the  chosen  physical  structure 

3.  define  user  views 

4.  access  the  defined  database 

5.  define  the  storage  structures  to  be  used  to  store 
the  data 

B.  RELATIONAL  DATABASE  IMPLEMENTATION 

Most  commercial  DBMSs  support  a  single  data  model 
[ Re  *  48],  The  relational  model  developed  during  the  data 

analysis  stage  is  implemented  using  a  relational  DBMS. 

There  are  three  main  types  of  relation  DBMSs.  There  are 
some  based  on  SQL.  others  are  based  on  QUEL.  and  a  third 
category  based  on  other  data  languages. 

One  major  problem  with  the  imp  1 emen t a t i o n  of  relational 
DBMSs  is  the  occurence  of  null  values.  A  null  value  means 


that  either  the  data  value  is  unknown  or  that  the  value  is 
inappl i  c  a  b  1  e  ,  Null  values  present  problems  when  they  are 
values  for  key  columns.  when  predicates  are  evaluated.  and 
when  relations  are  joined.  It  is  therefore  necessary  to 
identify  tnese  potential  problem  areas  and  to  impose  a 
constraint  where  null  values  are  prohibited. 

C.  DATABASE  MANAGEMENT  SYSTEM  SELECTION 

It  is  important  at  this  juncture  to  divide  the  problem 
of  DBMS  selection  into  two  broad  categories.  With  the  recent 
growth  of  the  m i c r oc omp u t er  and  the  associated  growth  in 
application  software.  a  special  class  of  DBMSs  has  been 
created.  DBMS  selection  for  large  systems  involves 
difficult  assessment  of  cost.  high  risk  in  terms  of  the  DBMS 
affecting  nearly  every  aspect  of  an  organ i za t  ion '  s 
information  processing.  and  difficulty  in  determining  what 
kind  of  data  model  to  use.  These  same  issues  are  not 
rplevant  to  the  microcomputer  user.  One  significant 
difference  between  microcomputer  systems  and  large  systems  is 
the  size  of  the  database  to  be  managed  can  be  several  orders 
of  magnitude  larger  for  large  organizations.  Another 
difference  is  that  personal  computer  systems  are  intended  for 
use  by  only  a  few  people.  Therefore.  all  the  problems 
associated  with  multiple  simultaneous  access  do  not  arise. 
Additionally.  the  general  area  of  backup  and  recovery,  which 
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is  critical  to  large  business  systems  is  given  little 
attention  in  microcompter  applications. 

DBMSs  for  microcomputers,  are  generally  designed  for  the 
no n pr ogr ammer  user.  They  differ  from  DBMSs  that  are 
supported  by  larger  computer  configurations  by  the  selective 
power  of  database  access  languages  and  the  interface 
provided  to  the  user.  Query  languages  in  personal  systems 
are  usually  restricted.  i.e..  each  query  must  address  only 
one  file  (altnough  many  new  systems  are  now  capable  of 
multiple  file  access).  The  solution  is  to  give  users  simple 
commands  and  require  them  to  formulate  complex  queries  as 
sequences  of  such  commands.  The  emphasis  of  these  systems  is 
to  provide  an  interactive  interface  that  enables 
non pr ogr ammer  users  to  easily  define  and  populate  databases. 
[Ref.  49] 

Most  personal  computer  D8MSs  are  relatively  easy  to  use. 
They  are  designed  to  provide  inexperienced  users  with  an 
elementary  subset  of  database  access  commands  and  then.  with 
experience.  to  proceed  to  more  sophisticated  operations. 

d8ASE-II  is  an  example  of  a  m i c r oc om pu t e r  DBMS.  It 
contains  three  major  components  to  allow  database  access: 

1.  a  query  processor  to  support  on-line  ad  hoc  queries 

2.  a  simple  procedural  language  to  store  pr e progr ammed 
queries 

3.  a  report  generator 
See  Figure  6.2.  [Ref.  50] 
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Unlike  DBMSs  for  large  computer  systems.  most  DBMSs  for 
n'crocomputers  are  relational.  The  dBASE-II  query  processor 
•upports  a  SQL-like  language.  dBASE-II  also  provides  a 
jrocedural  language  to  enable  preprogrammed  queries  to  be 
.pec^fied.  More  experienced  users  can  create  files  that  hold 
:uch  procedures  and  then  execute  them  as  required. 

Although  DBMSs  provided  for  personal  systems  usually 
;ontain  a  narrower  set  of  facilites,  they  are  still 
effective  for  limited  applications. 

The  most  common  approach  to  selecting  a  DBMS  is  feature 
indlys’s.  A  list  is  compiled  of  general  features  that 
;  h a r a c t er i ze  DBMSs.  A  partial  listing  of  example  features 
:  a  n  Pp  seen  in  Table  XX.  Next.  each  candidate  DBMS  is 
evaluated  on  the  basis  of  each  feature.  An  appropriate 
'■  a  n  k '  n  g  system  can  be  applied.  The  third  step  involves 
analy-’ing  all  the  features  in  terms  of  what  the 
organization  needs  are.  The  final  step  involves  developing  a 
final  score  for  each  of  the  candidate  systems. 

Tne  advantages  of  this  method  are  ':ts  simplicity  and  the 
appearance  of  being  a  rational.  quantitative  technique.  It 
is  also  expandable.  meaning  tnat  aUdit1' ona-1  criteria  can 
oe  added  easily  by  adding  one  or  more  levels  of  weighting  and 
aggregation  between  tne  detailed  features  and  tne  overall 
DBMS  score.  Evaluation  can  be  adjusted  to  find  the  optimum 
set  of  we’gnts.  Disadvantages  of  this  method  are  t 
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TABLE  XX 


Partial  Database  Management  System  Feature  L^st 

A.  VENDOR  SUPPORT 

1.  TRAINING 

2.  DOCUMENTATION 

3.  TECHNICAL  SUPPORT 

4.  VENDOR  CREDIBILITY 

5.  USER  EXPERIENCE 

B.  EASE  OF  USE 

1.  INITIAL  IMPLEMENTATION 

2.  DATABASE  DESIGN  CHANGE  FACILITIES 

3.  CONTINUING  USE 

C.  SYSTEM  REQUIREMENTS 

1.  HARDWARE 

2.  SOFTWARE 

D.  COMPLETENESS 

1.  SECURITY  FEATURES 

2.  UTILITIES 

3.  DATA  STRUCTURES  SUPPORTED 

4.  QUERY  FACILITIES 

5.  REPORT  WRITER  FACILITIES 

6.  BATCH/ONLINE  CAPABILITY 

7.  COMMUNICATIONS  INTERFACE 

8.  LANGUAGE  INTERFACE 

9.  DATA  DICTIONARY  CAPABILITY 

10.  USAGE  STATISTICS 

11.  SUPPORT  FOR  DATA  INDEPENDENCE 

E.  INTEGRITY 

1.  CHECKPOINT/RESTART 

2.  BACKUP/RECOVERY 

F.  PERFORMANCE 

1.  CPU  USAGE 

2.  CHANNEL  USAGE 

3.  TUNING  FLEXIBILITY 


VII.  EVALUATING  THE  DATABASE  DESIGN 


A.  DESIGN  OBJECTIVES 

Database  design  must  satisfy  a  certain  set  of  criteria. 
These  criteria  can  be  divided  into  two  major  classes: 
structure  and  performance  criteria. 

The  first  class.  structure  criteria,  concerns  the 
preservation  of  data  properties.  Specifically.  the 
preservation  of  data  properties  has  a  high  correspondence  to 
normal  relations  to  avoid  anomalies.  Additionally,  the 
preservation  of  integrity  links  between  object  sets  is 
critical  to  prevent  database  inconsistencies. 

The  second  class.  performance  criteria,  concern  resource 
use  and  database  access.  Performance  criteria  include 
transaction  requirements  that  must  be  met.  a  minimum  amount 
of  storage  should  be  used,  and  the  number  of  transfers 
between  memory  and  storage  devices  must  be  minimized. 

Due  to  the  nature  of  this  database  project,  only  the 
first  class  of  criteria  will  be  evaluated.  Performance 
criteria  are  important  in  m i c r oc omput er  DBMSs.  however.  the 
ability  to  control  them  is  often  limited.  These  criteria,  on 
the  other  hand,  are  critical  to  large  database  system  design. 
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B.  INITIAL  DESIGN 

The  goal  of  initial  design  is  to  produce  feasible  design 
structure,  one  that  will  not  be  optimized  but  will  satisfy 
all  access  requirements. 

The  design  structure  must  ensure  that  records  needed  by 
on-line  transactions  can  be  accessed  directly.  Otherwise  the 
database  system  will  become  bogged  down  in  DML  operations  to 
retrieve  requested  data  and  the  system  will  be  less 
eff ic ient . 

Design  methods  use  a  variety  of  logical  and  physical 
design  techniques  and  apply  them  to  realize  designs  that 
satisfy  the  design  criteria.  These  techniques  are  applied  in 
sequences  that  depend  on  the  DBMS  and  on  the  relative 
importance  placed  on  the  two  classes  of  criteria.  [Ref.  51] 

C.  DESIGN  ITERATIONS 

Once  the  initial  design  is  accepted.  the  designer 
attempts  to  improve  it.  Various  design  trade-offs  are  made 
to  reach  an  optimum  design. 

After  design  problems  are  identified.  the  designer  can 
select  various  design  tactics  to  overcome  them.  Ideally,  a 
set  of  design  tactics  are  provided  for  each  problem.  It  is 
beyond  the  scope  of  this  paper  to  go  into  more  detail 
concerning  design  iterations  and  design  tactics. 
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D.  EVALUATING  DATABASE  DESIGN 

Database  evaluations  are  made  at  all  the  system 
development  steps.  Stepwise  evlauation.  however,  will  not 
ensure  the  optimum  final  design.  Successive  steps  use  the 
performance  estimates  to  indicate  design  problems  and  then 
design  tactics  are  used  to  correct  these  problems.  At  this 
point  the  design  is  then  implemented  on  the  DBMS. 

The  benefits  of  database  systems  are  obtained  only  after 
the  design  and  implementation  are  completed,  and  after 
sufficient  data  has  been  collected  so  that  the  user  of  the 
database  can  receive  usable  information.  The  remainder  of 
the  database  cycle  will  involve  assurance  of  reliability  and 
quality,  adaptation  to  changing  requirements,  and  eventually 
termination  of  the  operation  with  transfer  of  valuable  data 
and  procedures  to  a  new  system.  [Ref.  52] 

Once  the  database  design  has  been  finalized  and  the  data 
loaded,  performance  improvement  involves  finding  the  most 
efficient  route  to  the  data  required  by  each  query.  This  is 
accomplished  by  looking  at  the  specific  data  model  and 
selecting  the  shortest  path.  One  important  question 
concerns  when  the  access  path  selection  is  made.  The  two 
choices  are:  when  the  retrieval  program  is  written  or  when  it 
is  executed.  The  other  major  question  is  whether  the  access 
path  decision  is  made  by  the  DBMS  or  by  either  the  user  or 
pr ogr  ammer  . 
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One  of  the  basic  precepts  of  the  relational  model  is 
that  access  path  decisions  should  be  made  by  the  DBMS  and. 
ideally,  not  until  the  query  is  processed.  In  theory,  this 
should  be  the  optimal  approach.  Waiting  until  execution  time 
to  make  the  access  decision  means  that  it  can  take  into 
account  the  exact  state  of  the  database  at  that  moment. 
Placing  responsibility  on  the  DBMS  could  be  viewed  merely  as 
a  convenience  to  users,  but  acually  it  should  be  interpreted 
as  an  assertion  that  the  system  is  better  able  to  make  these 
decisions  than  the  user.  [Ref.  53]  In  the 

microcomputer  DBMS.  this  is  especially  true  considering  that 
most  database  users  fall  into  the  casual  user  category. 

One  method  of  improving  database  design  to  increase 
performance  is  the  addition  of  extra  indices.  Normally, 
an  index  will  be  maintained  on  the  values  of  the  key  data 
elements.  This  allows  efficient  retrievals  where  the  key 
values  are  known  because  the  index  can  be  used  to  find  the 
relevant  records  without  searching  each  tuple.  It 

works  much  the  same  way  as  you  would  use  the  index  in  the 
back  of  a  book  when  looking  for  a  specific  topic.  Many 

systems  allow  the  designer  to  specify  that  additional  indices 
should  be  created  and  maintained  for  nonkey  data  elements 
that  are  the  basis  for  frequent  retrieval  requests. 

Indices  are  not  automatically  created  for  all  data 
elements  because  there  are  costs  involved.  They  take  up 
storage  space  in  memory.  The  decision  whether  to 


create  additional  indices  depends  on  knowing  something  about 
the  relative  frequency  of  updates  and  retrievals.  If 
retrievals  are  far  more  numerous  than  updates,  then  an  index 
should  be  considered.  If  updates  occur  about  as  often,  or 
more  often  than  retrievals,  then  the  extra  work  required  to 
maintain  the  index  will  probably  not  be  profitable.  This 
illustrates  the  problems  associated  with  optimizing  database 
design  without  knowing  actual  useage  requirements. 

The  bottom  line  is  to  make  sure  that  the  system  supports 
the  user  the  way  it  should.  If  it  does  not.  successive 
design  iterations  are  performed  until  it  does.  See  Figure 
7.1. 
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Figure  7.1  Design  Iterations 


VIII.  RECOMMENDATIONS 


This  thesis  proposes  an  initial  design  for  a  relational 
database  system  that  will  support  asset  identification  and 
valuation  as  the  first  step  to  conduct  computer  risk 
assessment  at  NPS.  Much  work  remains  to  be  done  before  this 
system  can  be  used. 

The  remaining  tasks  of  DBMS  selection  and  implementation 
would  be  excellent  for  student  thesis  work.  I  would 
recommend  that  the  available  microcomputer  DBMS  systems  be 
evaluated  and  that  one  be  selected  for  implementing  this 
database  design.  There  are  several  DBMSs  available  at  NPS 
including  RBASE  4000.  POWERBASE.  dBASE  II  and  10BASE.  I 
recommend  that  a  microcomputer  DBMS  be  used  because  they  are 
designed  for  users  with  little  computer  expertise. 
Users  can  also  maintain  control  and  security  of  the  system 
easily  (a  matter  of  locking  up  system  and  data  diskettes). 

The  DBMSs  listed  above  can  handle  files  of  about  6.000 
to  10,000  records  with  "acceptable"  delays  (10  second 
retrievals.  1  hour  sort  times).  Additional  work  is  required 
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essential  for  effective  operation  of  the  database  system. 
He  is  responsible  for  protecting  the  database  while  at  the 
same  time  maximizing  benefits  to  users. 

The  users  of  the  system  must  also  be  identified.  It  is 
not  clear  who  will  be  required  to  perform  the  task  of  data 
collection  and  data  entry,  or  who  will  have  to  generate 
reports  for  the  purpose  of  controlling  computer  resources. 

It  is  possible,  due  to  the  nature  of  this  database,  that 
the  user(s)  would  also  act  as  admi n i stra tor .  With  proper 
database  design  and  careful  implementation,  and  employing  a 
high  level  language  interface,  even  casual  users  would  be 
able  to  manage  this  system.  Naturally.  appropriate 
documentation  and  training  would  have  to  be  provided.  Also, 
postdesign  optimization  and  changes  to  the  system  would 
require  the  skills  of  a  more  sophisticated  computer 
technician. 

Many  of  these  recommendations  hold  only  if  the  database 
system  is  implemented  on  a  personal  computer.  If  the  system 
is  implemented  on  a  larger  computer  system  the  problems  are 
much  more  complex. 

One  disadvantage  of  implementing  the  database  system  on 
a  personal  computer  is  that  access  is  somewhat  restricted. 
Anyone  needing  access  to  the  system  will  have  to  know  where 
to  go  and  request  permission  to  access  the  system  from  the 
owner.  This  problem  can  be  alleviated  somewhat  by  creating  a 
computer  network  and  sharing  this  data  between  multiple 
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microcomputers.  It  is  possible  to  link  microcomputers 
together  either  with  modems  and  telephone  lines  or  by  using 
commercially  available  network  technology.  There  are. 
however.  problems  with  computer  networking  and  database 
operations.  Extensive  research  is  required  in  this  area 
before  an  approach  could  be  recommended. 

This  initial  design  covers  only  the  asset  identification 
and  valuation  aspects  of  computer  risk  assessment  procedures. 
The  global  risk  assessment  database  system  depicted  in  Figure 
9.1.  must  also  be  designed  and  implemented  before  the  system 
will  provide  help  with  the  overall  risk  assessment  process. 
The  initial  design  has  been  constructed  so  that  it  can 
be  easily  expanded  to  incorporate  the  global  risk  assessment 
process.  This  decomposition  of  the  database  design 
simplifies  the  problem  by  enabling  the  designer  to  focus  on 
individual  modules  one  at  a  time. 


IX.  CONCLUSIONS 


There  is  growing  pressure  to  control  the  growth  of 
computers  throughout  government  due  to  the  enormous  sums  of 
money  that  are  spent  on  computer  equipment  every  year.  The 
rapid  infiltration  of  computers  into  all  areas  of  operations 
within  government,  and  the  Navy  in  particular,  has  led  to 
increased  reliance  on  computers  to  perform  its  mission. 
Organizational  dependence  on  computers  has  made  it  necessary 
to  continually  assess  vulnerability  to  threats  related  to 
computer  resources. 

Numerous  directives  have  been  promulgated  to  help 
identify  threats  to  computer  resources  and  recommend 
methodologies  to  perform  risk  assessment.  The  risk 
assessment  procedure.  however.  requires  a  great  deal  of 
effort  and  the  procedure  itself  would  be  well  served  by 
employing  database  technology.  A  database  would  greatly 
enhance  the  process  by  providing  a  standardized.  well 
structured.  and  maintainable  vehicle  with  which  to  compute 
the  annual  loss  expectancy  for  comuputer  resources  of  a  given 
organization. 

A  global  data  structure  digram  has  been  devised  to 
provide  such  a  database.  Figures  3.3  and  3.4  show  the  global 
system  f  u  n  c  t ; on  n-erarchy  and  data  structure  diagram 
respectivly.  One  ’  n  a  .  i  d  u  a  1  user's  view  has  been  designed  as 
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e.  Commun i  c  a  t  i  o  n  s  :  Number  of  nodes  (locations),  and 

number  of  terminals 

f.  Networks  (e.g..  AUTODIN  interface.  TELNET.  ARPANET) 

g.  TEMPEST  required:  yes  or  no.  as  applicable;  if  yes. 
provide  TEMPEST  task  number 

h.  Is  COMSEC  required?  (yes  or  no) 

i.  Is  DES  required?  (yes  or  no) 

9.  Estimated  schedule  for  completing  accreditation: 

a.  Risk  assessment:  estimated  s t a r t / c om pi e t i o n  dates 

b.  ST&E:  plan  development  date;  test  date 

c.  Contingency  Plan  development  date 

d.  Date  for  submitting  request  for  accreditation 

10.  Name  of  ADP  systems  security  officer  (ADPSSO) 
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Activity  accreditation  schedule  sample  format 


Legend  explanation: 

1 .  Name  and  address  of  activity 

2.  Commanding  Officer's  name  and  telephone  number.  AUTQVON 
and  Commercial 

3.  UIC  -  Unit  Identification  Code 

4.  ADP  Security  Officer  (AOPSO)  name  and  telephone  number. 
AUTOVON  and  Commercial 

Provide  the  following  informa:  n  {items  5  through  10)  for 
each  ADP  element  of  the  activity: 

5.  DAA  -  Designated  Approving  Authority  -  Commanding 
Officer.  COMNAVDAC.  Director  of  Naval  Intelligence,  or  Chief 
of  Naval  Operations  (OP-942) 

6.  Level  of  processed  data  (I,  II.  and  III) 

7.  Modes  of  operation  -  System  high,  dedicated,  controlled, 
multilevel 

8.  ADP  element  ■information: 

a.  Application  name  (e.g..  payroll,  logistics,  finance, 
UADPS  Stockpoints,  OSIS,  SHARE/7.  NACMIS.  etc.) 

b.  Hardware  (CPU)  manufacturer  (e.g..  IBM  3081.  Uni  vac 
1160.  etc.) 

c.  Software  (operating  system)  (e.g..  Univac  (Exec 
1100)  ) 

d.  Facility,  building  number/room  number 
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I  1  ■linl  k  l 


Activity  accreditation  schedule  sample  format  continued 


s.  uic  _ 

4.  ADPSO  NAME/TELEPHONE  • 


AUTOVON  _ 

COMMEXQAL 


s.  Acnvrn  adp  elements 


E. 

COMM. 

*  NODES/ 
TEIMINALS 

H 

rTTtTTrj  <-«»] 

E 

□ 

c 

23 

S.  ESTIMATED  SCHEDULE 
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DBS 

IEQUIIED 

H 

B. 

ST  A  E 
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CONT 

PLAN 

D. 

ACCRED¬ 

ITATION 

NAME 

OP 

ADPSSO 

ffH 

APPENDIX  B 

AN  EXAMPLE  OF  THE  ACTIVITY  ACCREDITATION  SCHEOULE 
Activity  accreditation  schedule  sample  format 


I.  NAME  ft  ADDRESS 
OP  ACTIVITY 


2.  CO'S  NAMS/mSPHONE  • 


AUTO VOW 
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An  example  of  OPNAV  5239/13, 
SELECTION  WORKSHEET 


ADDITIONAL  COUNTERMEASURES 


ADDITIONAL  COUNTERMEASURES  SELECTION  WORKSHEET 

ggggg 

f'jr 
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ORIGINAL 

ALB 

D. 

REVISED 

ALE 

E. 

ANNUAL 

SAVINGS 

P-  ANNUAL 
COSTOP 
ADDITIONAL 
COUNTERMEASURES 

a 

RETURN 

ON 

INVESTMENT 

R  ADDITIONAL 
COUNTER¬ 
MEASURES 
PRIORITIES 
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A. 

■ 

■ 
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E. 

E. 

H. 

E. 

ANNUAL  SAVINGS  SUBTOTAL 

2. 
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s 

■ 

c 
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■ 

■ 

u 
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■ 

■ 

1. 

E. 

E. 
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An  example  of  OPNAV  5239/12,  RISK  ASSESSMENT  MATRIX 
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An  example  of  OPNAV  5239/11.  ADDITIONAL  COUNTERMEASURES 
SUMMARY  LISTING 


An  example  of  OPNAV  5239/10,  ADDITIONAL  COUNTERMEASURE 
EVALUATION  WORKSHEET 
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An  example  of  OPNAV  5239/9.  ALE  COMPUTATION  WORKSHEET 


ADDITIONAL  COUNTERMEASURE  EVALUATION  WORKSHEET 

1.  COUNTERMEASURE  NAME 

2.  ANNUAL  COST 

3.  DESCRIPTION 

4.  THREATS  AFFECTED  BY  THIS 

3.  ALE 

6.  ALE 

COUNTERMEASURE 

PROJECTED 

SAVINGS 

7.  RETURN  ON  INVESTMENT 

S.  TOTAL 

ALE 

SAVINGS 

9.  OVERLAPPING  ADDITIONAL  COUNTERMEASURES 

An  example  of  OPNAV  523P/8.  THREAT  AND  VULNERABILITY 
EVALUATION  WORKSHEET 


THREAT  AND  VULNERABILITY 
EVALUATION  WORKSHEET 


2.  DESCRIPTION.  EXAMPLES.  AND  JUSTIFICATION  BASED  ON 
EXISTING  COUNTERMEASURES  AND  VULNERABUJTES. 


3.  SUCCESSFUL  ATTACK  FREQUENCY  RATING  BY  IMPACT  AREA. 

□  modification  □destruction  □disclosure  □  DENIAL  OF  SERVICE 
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APPENDIX  A 


EXAMPLES  OF  VARIOUS  FORMS  USED  IN  THE  RISK  ASSESSMENT  PROCESS 
An  example  of  OPNAV  5239/7,  ASSET  VALUATION  WORKSHEET 


ASSET  VALUATION  WORKSHEET 

1.  ASSET  NAME 


2.  ASSET  DESaUPTION  AND  JUSTIFICATION  OF  IMPACT  VALUE  EATINGS  ASSIGNED. 


3.  IMPACT  VALUE  EATING  BY  IMPACT  AEEA 

□  MODIFICATION  □  DESTRUCTION  □  DISCLOSURE  □  DENIAL  OP  SEBVICE 


09 


the  beginning  step  toward  creating  an  itegrated  database 
system.  The  initial  design  for  asset  identification  and 
valuation  has  been  presented  in  this  thesis. 

The  relational  model  was  chosen  because  its  tabular 
interface  can  be  easily  understood  by  database  users  and 
because  most  microcomputer  DBMSs  are  built  on  the  relational 
model  . 

Much  worx  remains  to  be  done  on  this  data  model.  Users 
need  to  be  identified  and  responsibility  for  the  database 
must  be  assigned.  A  DBMS  must  be  selected  for  implementing 
the  model  and  data  must  be  collected  and  entered  into  the 
database.  These  are  difficult,  time  consuming  tasks  which 
can  be  completed  by  students  in  the  various  computer 
technology  curricula. 
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